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FOREWORD 


In early FY 1974, the Logistics of Orbiting Vehicle Servicing 
(LOVES) computer specification was developed as a part of NASA Study 2 6, 
Operations Analysis This specification defined a computer code which 
could be developed to simulate space servicing of satellites, an alternative 
approach to ground refurbishment with the potential for significant reduc- 
tion of future operational and program costs From this specification and 
through a series of evolutionary discussions, the LOVES Computer Program 
was developed. 

The LOVES Computer Program is designed to simulate the 
logistics of on-orbit servicing using the Shuttle and an upper stage to deploy 
satellites and subsequently replace individual modules in the satellites The 
primary use of the program is for parametric studies and changes in opera- 
tional policy as they impact vehicle flight rates and satellite availability The 
program was developed in the CDC 6400/7600 computer complex at The Aero- 
space Corporation, El Segundo, California, for implementation on a UNIVAC 
1108 computer. It is coded in SIMSCRIPT 1.5 and FORTRAN IV. SIMSCRIPT 
(simulation of a program used for design and development purposes) is a sim- 
ulation language originally developed at the Rand Corporation and now avail- 
able from Consolidated Analysis Centers, Inc , (C.A. C I.) in Santa Monica, 
California. FORTRAN IV (Formula Translation System) is a standard 
scientific programming language in common use in computer programs 

At the direction of V. N. Huff, NASA Task Monitor (Code MTE), 
NASA Headquarters, Washington, D G., the LOVES Computer Program has 
already been delivered for use at the NASA Computing Facility in Slidell, 
Louisiana, and to Dr. J Steincamp at the Marshall Space Flight Center, 
Huntsville, Alabama. 

Documentation provided under NASA Study 2. 1 includes 
this report and a companion report, ATR-74(7341)-7, Operations Analysis 
(Study 2 1), Program Listing for the LOVES Computer Code. In addition. 
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potential users of the LOVES Computer Program are referred to the 
original specification document prepared under NASA Study 2 6, 
ATR-74(7336)-3, Operations Analysis (Study 2 6) Final Report, Volume IV 
Computer Specification -- Logistics of Orbiting Vehicle Servicing (LOVES). 
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1. INTRODUCTION 


This document provides the potential user with the 
information necessary to use the LOVES Computer Program in its 
existing state or to modify the program to include studies not properly 
handled by the basic model. The report is divided into a Users Guide, 
a Programmers Manual, and several supporting appendices. To achieve 
a full understanding of the LOVES Computer Program will require at 
least a perusal of the entire document. 

The Users Guide defines the basic elements assembled 
together to form the model for servicing satellites in orbit. As the 
program is a simulation, the method of attack is to disassemble the 
problem into a sequence of events, eacn occurring instantaneously and 
each creating one or more other events in the future The main driv- 
ing force of the simulation is the deterministic launch schedule of 
satellites and the subsequent failure of the various modules which make 
up the satellites 

The user will find a description of the events in the simu- 
lation along with the properties of satellite systems, satellites, modules, 
orbits where satellites "live, " and vehicles (upper stages. Shuttles, and 
the Solar Electric Propulsion Stage). The phasing algorithm is des- 
cribed as it pertains to visiting several payloads positioned at different 
locations within an orbit. The loading queue is discussed as the means 
of choosing when a latuich shall occur. There is also a discussion on the 
detail of the data cards contained in the input data deck. 

The LOVES Computer Program uses a random number 
generator to simulate the failure of module elements and therefore 
operates over a long span of time — typically 10-15 years. The sequence 
of events is varied by making several runs in succession with different 
random numbers resulting in a Monte Carlo technique to determine sta- 
tistical parameters of minimum value, average value, and maximum value. 
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The parameters collected are described in the paragraphs on program 
output. 

The Programmers Manual presents a series of flow 
charts showing the interconnections between all the subroutines and 
events which the program comprises. Each subroutine and event is 
then described in some detail. It should be noted that experience in 
working with the program has demonstrated that changes can rarely be 
localized to one routine but rather must be integrated into the entire 
conglomerate. 

Appendix A describes the queues (waiting lines) used 
to retain a record of satellite launchings, payloads ready to fly (load- 
ing queue), and the next event to occur in the simulation. 

Appendix B defines the variables used in the LOVES 
Computer Program and provides some insight into the internal operations. 

Appendix C provides a sample printout which should be 
produced by the original program (the code is in another document) if 
the user inputs the data included in the appendix. 
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2 USERS GUIDE 


This section is intended to acquaint the user with 
the capabilities of the LOVES Computer Program. The section 
contains descriptions of the events being simulated, the construc- 
tion of systems, satellites, and modules, the vehicles used to trans- 
fer to orbits, and the algorithms used in the Monte Carlo simulation. 

2. 1 SIMULATION ELEMENT INTERRELATIONSHIPS 

2. 1 1. Event Flow 


The LOVES Computer Program is a simulation of an 
on-orbit servicing process The simulation model has been set up 
as a series of events with each event having a time of occurrence. A 
typical sequence of events is shown in the list below 


BEGIN 


START 


NWS AT 


LAUNC 


ARRIV 


initiates the simulation, reads in data 
to define the span of years for the simu- 
lation, causes all data to be loaded, 
sets up the next event, START, and 
never occurs again. 

initializes data for the Monte Carlo 
cycle, sets up all required NWSAT 
events from input data, and sets up 
the last event, TERM 

confirms that a satellite is available 
for launch and is placed in the loading 
queue and sets up the mandatory launch 
event, LAUNC. 

signifies that a launch must occur now. 

The payloads are removed from the 
loading queue and arrival events, ARRIV, 
are set up for each payload. The event 
REFVE is set up. The events REMOV 
and BACK may be optionally set up. 

indicates that a payload has arrived at 
its designated position and become opera- 
tional. The optional events (FAIL, WARN, 
SATDN, NWSAT, and RETRI) may be set 
up for each module or the satellite. 
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REFVE 


WARN 


FAIL 


RETRI 

SATDN 

REMOV 

BACK 

TERM 


shows that the vehicle has completed 
flight and refurbishment and is now 
ready for use. The loading queues 
are checked for flights not flown 
because of lack of vehicles (in which 
case, the functions of LAUNC are per- 
formed at this time), 

provides notice that a warning of impend- 
ing module failure has been received A 
replacement module is put into the loading 
queue. Any payload put into the loading 
queue may create a condition where a 
vehicle could not be flown (in which case, 
the functions of LAUNC are performed 
on a portion of the loading queue). The 
mandatory launch event, LAUNC, for 
this module is optionally set up. 

signals that a module failure has occurred. 

A replacement module is put into the load- 
ing queue if a warning has not been received 
previously. The mandatory launch event, 
LAUNC, for this module is optionally set 
up. 

notes that retrieval of a satellite is sched- 
uled to occur now. The request for retrieval 
IS entered into the loading queue (which will 
force the REMOV and BACK events). 

IS used when a satellite is permanently deac- 
tivated at the end of its life. 

indicates the satellite is physically docked 
with a vehicle as the first step of retrieval, 

shows when the satellite has reached the 
earth's surface. 

IS the last event to occur. It may decide to 
terminate the run or reset the simulation 
clock and set up the event START for another 
integration through the sequence. 


The typical simulation run consists of 15-200 initial setups 
of the event NWSAT which cascade into arrivals, warnings, and failures at 
the rate of 1-25 modules /satellite. The SIMSCRIPT system performs the 
booking function of selecting the new next event to occur, even if two or 
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more occur at the same time. For more detail on options, see the 
input data description and the Programmers Manual portion of this 
document. 

In addition to the basic sequence of events shown, 
there are three more options available, although none of them has 
been required in the simulations performed to date. The three addi- 
tional events are 


REFMO - 

occurs when a module completes 
refurbishment and is available for 


reuse. 

REFSA 

provides notification of the comple- 
tion of satellite refurbishment. 

NEWME - 

confirms that a new mission equip- 
ment module is available for launch. 


The module is placed in the loading 
queue, and a mandatory launch event, 
LAUNC, IS set up. 


2.1.2 Satellite Systems 

Satellite systems usually consist of a number of satel- 
lites located in various orbits or at various positions around an orbit 
so that they can be separated in angle. A system can also have all of 
its satellites in the same orbit and may have them clustered together 
in the orbit. The user has the option of defining any mix between the 
two extremes. 

If a system is defined as having four satellites at more 
or less unique positions, the program reserves four satellite positions 
in orbit as belonging to that system. During a span of say 12 years, 
the program may satisfy the user's intentions by deploying a total of 
15 satellites to the 4 positions Occasionally, due to an input data error, 
the summary printout may show no satellites deployed to a specific posi- 
tion in a system. 

A system can be said to be operational if some number 
of the satellites are each operational. This definition can be interpreted 
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to mean a system is operational if all satellites are operational with 
active spares (the spare can be temporarily operative, inoperative 
due to module failure or end of satellite life, or not yet deployed). 

The system has the property of a lifetime which is 
measured from the time the first satellite becomes operational. At 
the end of the system lifetime, all satellites are disabled, and no 
more deployments should be made to any satellite position in the 
system. 

A low development rate and a limited lifetime for each 
satellite in the system can lead to a premature termination of the sys- 
tem, thereby yielding a shorter than expected system lifetime. Over 
the period of the lifetime, statistical information is gathered for eval- 
uation of the system performance in conjunction with whatever policies 
and constraints the user has imposed on the run. For each system, the 
minimum, average, and maximum values for the following parameters 
have been printed as shown in Appendix C 


a. 


b. 


c. 


2 . 1.3 


System Total Flights - the total of all the load factors 
for modules and satellites as chargeable to this system 
in a Monte Carlo cycle. It is interpreted as the total 
equivalent flights of the uppermost vehicle in the 
delivery cycle. 

Percentage System Available - the percentage ratio of 
the total of all time intervals that the system was opera- 
tional to the actual lifetime for each Monte Carlo cycle. 

Delay Interval to Restore - the interval in days between 
the moment the system became inoperative and the 
moment following when the system returned to opera- 
tional status for each and every outage interval. 

Satellites 


The satellites are used as members of the systems, 
and a satellite may be used as many times as necessary in any number 
of systems. The program retams, as a part of the system information, 
which satellite is at each position. Thus, the user need only define the 
satellite once and then may refer to the same data as many times as neces- 
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sary. For example, on page C-8 in Appendix C, the system NNDIAB 
contains the satellite NNDIA, NNDIB, NNDIA, and NNDIB. These 
data defined NNDIA and NNDIB previously, and the system specifica- 
tion makes reference to NNDIA and NNDIB each twice, thereby caus- 
ing the program to generate two of each of the two satellites at the 
satellite positions in orbit, 

Similarily, the satellites are made up of modules 
each defined in a module table. Each satellite can use as many mod- 
ules as necessary, some of them repetitively for the module can be 
manufactured in lots The user defines the module once and thereafter 
can refer to the data by name as many times as necessary. The data 
for each module on each satellite at each satellite position are main- 
tained by the program. 

A satellite can be said to be operational if a single 
strand module and all redundant subsystems are operational. Redun- 
dant subsystems contain active spares only. The satellite has the 
property of a lifetime which is measured from the time the satellite 
becomes operational after deployment of an entire satellite. At the 
end of the satellite lifetime, the satellite and all of its modules are 
disabled. The satellite position can be reactivated by a new deploy- 
ment, resulting in a new life span at the satellite position. This 
feature permits the user to define a long-lived system using short- 
lived satellites. 

Satellite deployments are performed by two features 
in the program The user can stipulate via input data the date at which 
each satellite becomes available for launch This is required for the 
initial satellite launch to each satellite position, as the delivery schedule 
IS an integral part of the mission model being simulated Some satellite 
systems have holes in operational schedules during which, for budgetary 
or other reasons, no active satellites are available. Where applicable, 
the user can request automatic replacement of satellites over the span 
of the systems. The parameter POLIC is a property of each satellite. 
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A normal value of 0 {is equivalent to 1) means no replacement. If 
POLIC IS 2 or 3, the replacement satellite becomes available WAITl 
days after termination. If WAITl is negative, the new satellite could 
replace the previous satellite with no system outage. If POLIC is 3 
or 4, the old satellite will become available for retrieval after the 
interval WAITl + WAIT2 after the termination. WAIT2 is typically 
+ 1 day, depending on the users preference of deployment over retrieval 
in conjunction with outage. 

For each satellite on each system, the minimum, 
average, and maximum values for the following parameters have 
been printed as shown in Appendix C. 


a. Satellites Deployed - the average number of satellites 
deployed only. 

b. Satellite Deployment Flights - the total of chargeable 
flights for satellite deployment only. 

c. Satellite Total Flights - the total of all the load factors 
as chargeable to this satellite position in a Monte Carlo 
cycle. 

d. Percentage Satellite Available - the percentage ratio 
of the total of all time intervals that the satellite was 
operational to the actual lifetime for each Monte Carlo 
cycle. 

e. Delay Interval to Restore - the interval in days between 
the moment the satellite position became inoperative and 
the moment following when the satellite position returned 
to operational status for each and every outage interval 


2. 1. 4 Modules 

The basic elements of a satellite are modules which 
can be classified as SRU or NRU. An SRU (space replaceable unit) is 
a module that is packaged in a single unit and can be physically removed 
and replaced in the satellite. Examples of SRUs are attitude control 
units, electrical power systems, sensors, on-board computers, telemetry 
and data communication units, etc. An NRU (non-replaceable unit) might 
be the structural shell of the satellite, the wiring harness connecting all 
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modules together electrically, or a replaceable unit mounted in the 
interior of the satellite where it would be impractical to replace. The 
major distinction between SRUs and NRUs is that an SRU replacement 
amounts to delivery of typically 200 pounds whereas an NRU failure 
forces replacement of the entire satellite amounting to typically 1500- 
5000 pounds. 

Regardless, a module has the properties of weight, 
lifetime, and the Weibul parameters, ce and , for both failures 
and warnings. The lifetime is an interval at the end of which the mod- 
ule IS inoperative, and in the case of an SRU, it will be replaced. This 
property is applicable to batteries and propellant bottles which should 
be replaced at known intervals A module failure can be deduced from 
telemetry data or other observations, and similarily a degradation in 
performance can be observed down to a limiting criteria (warning). 

No two modules behave the same way, and therefore the program pre- 
dicts the failure and warning of each module by selecting a random 
number and transforming it to a time of failure and warning by means 
of the Weibul function 


R = 

where 

t 

R 

a 

and 

Some modules do not give warnings of degradation (or the 
user may not wish to respond). This is accomplished by setting the Ot for 
warning to zero. Similarily, no failures will occur for modules with the 0£ 
for failure set to zero This is important for interplanetary satellites where, 



is the time elapsed since the module became 
operative, 

IS the probability of failure or warning, and 
are properties of the module 
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for the purposes of determining flights, it is undesirable to attempt 
to replace a module and the satellite will terminate eventually anyway. 

A module on a satellite has an operative or inopera- 
tive status. The occurrence of a warning does not affect the module 
status. A module becomes operational when the satellite is deployed 
in orbit or when the module is replaced. The occurrence of a failure 
makes the module inoperative. Whenever a failure or a warning occurs, 
the replacement is scheduled except when the flight would be too near 
the end of the life of the satellite (which would be a wasted flight). 

Again, there is an exception in which an NRU failure or warning can 
force the replacement of the satellite thereby extending the life at 
the orbital position. 

The program does recognize subsystems as consisting 
of a redundant set in which n out of m modules are required for the sub- 
system to be operational (n < m). Also, certain non-cntical modules 
(some scientific experiments for example) bear no relationship to the 
primary functions of the satellite. Failure of these modules does not 
affect the status of the satellites. All other module outages, single 
strand and subsystems, can force the satellite to become inoperative. 

The launch of the modules is facilitated by a service 
unit weighing approximately 400 pounds with a length of 8 feet and capa- 
ble of holding 16 modules. All the numerical values can be found in 
the sample input in Appendix C. As many service units as necessary 
will be put on the flight. The flag PDOWN controls the retrieval of 
modules, if it is 0, all service units and modules are returned to the 
ground, and, if it is not 0, the items are left as a group at the last 
orbit position serviced by the flight. The flag EXMOD controls the 
SRU/NRU replacement, if it is 0, the program is as has been described. 
If it IS 100, SRU failures suddenly act like NRU failures, and, if it is 
any other value, the NRUs act like SRUs. 

The program is to be capable of permitting the user 
to specify the change of a module known as the mission equipment 
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upgrade Based on the premise that with the passage of time, better, 
more reliable units will evolve, the user can stipulate the replacement 
of a module on a specific satellite in orbit on a specific day. 

Two classes of statistics are gathered for modules. 

Each satellite position in orbit has a string of modules attached to it 
describing the makeup of the satellite For each module at each satel- 
lite position, the minimum, average, and maximum values are computed 
for the following parameters the number of times a replacement module 
was launched in this Monte Carlo cycle, and the load factors for deploy- 
ment of the replacement module including pr oration of the service unit 
on the flight. The other class is the module table in which the module 
appears only once. The minimum, average, and maximum values accrued 
over a Monte Carlo cycle are computed for the number of warnings, fail- 
ures, and actual replacements. 

2, 1, 5 Orbits 

Each satellite is assigned to a specific orbit, and many 
different satellites can be assigned the same orbit, i. e., geosynchronous. 
Orbits are identified by a name and have specific propert ies. Vehicles 
are assigned to fly transfer trajectories from the earth's surface via 
Shuttle to near-earth orbit and thence via an upper stage to final orbit or 
via an upper stage plus the Solar Electric Propulsion Stage (SEPS). The 
required A V for the upper stage to fulfill on the last leg is provided. The 
A V should include any necessary plane changes 

Statistics are gathered for the activity of each orbit. The 
program will report the average number of flights to the orbit and the 
average total payload weight deployed on those flights. 

2. 1 6 Outage and Availability 

The LOVES Program measures the parameters of out- 
age and availability at both the system and the satellite levels. Consi- 
der the diagram in Figure 1 for the Astronomy ID Satellite system from 
the printout on page C-13 of Appendix C. Both satellites and the system 
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1 

1 

i 

Date 

Member 
1 2 

1 

Action or Event 


A ST ID 

A ST ID 



1/2/83 

2/27/83 

2/27/83 






Both satellites become available for launch. 
The two are launched on the same flight. 

1 

The two become operational and the system 
IS operational (6 hours lag for flight). 














8/20/83 

Module TTC5 fails. Member No. 1 inoper- 
ative and system inoperative. 




( 


11/20/83 

Module TTC5 launched and replaced. All 
elements operational. 


1 

3 



0/0/84 

All elements retired from operational status 
due to termination of model. 





NOTE 

S ■ 1 

Interval C is when the second member of the system was oper- 
ational. Due to the nature of the example, intervals A and B 
are when both the first member and the system were operational. 


Figure 1. Diagram of Astronomy ID Satellite System Activity 
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became operational at the same time. This is an exception, for gen- 
erally the members of a system arrive in a staggered order. The 
module TTC5 failed which resulted in the satellite and the system 
becoming inoperative. The outage period between intervals A and B 
IS charged to both the satellite and the system as a delay interval to 
restore (90 days). Member 2 has no delay intervals to restore for 
this Monte Carlo cycle. Member 2 is 100 percent available in the 
sample, and both member 1 and the system have an availability of 
100 • /C which IS 66 percent. 

The more usual situation is one in which several 
modules on the same satellite may fail at nearly the same time but 
not be replaced at the same time. The outage for the satellite is 
measured from the moment the satellite becomes inoperative until 
the moment it returns to operational status Subsystems containing 
redundant module groups tend to improve availability and decrease 
outage as the satellite may be operative with a failed module in a 
particular subsystem. The outage on systems is complicated by 
overlapping inoperative intervals for satellites and by delays in the 
initial deployment of the necessary number of operative satellites 
(first arrival starts the system clock). 
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2. 2 OPERATIONS AND PHASING 

2. 2. 1 Vehicles 

The LOVES program divides vehicles into three classes 
and handles each class uniquely. 

The Shuttle must be defined on at least one data card. The 
user can define more than one Shuttle to provide for orbital maneuver- 
ing system (OMS) kits or flights to other than the nominal parking orbit. 
The important parameters of Shuttles are the total weight delivered to 
orbit, the maximum length of the payload in the bay, and the number of 
days required for refurbishment. 

The upper stage class can consist of one or more of the 

following typical vehicles Centaur, transtage, transtage with one or 

two solid kick stages, tandem Tug, and the full-capability Tug. The 

important parameters are gross weight of vehicle, dry stage weight, 

unused propellant, engine I , refurbishment time, maximum payload 

s p 

length, number of stages, and solid/liquid stage indicator. 

The SEPS class is restricted to only one vehicle via input, 
and only one is ever active in the simulation (fleet size is one). This 
feature of the program is implemented but is not completely operational 
as yet. 

Each class of vehicles is treated as an aggregate, that is, 
if there is a fleet of 10 Centaurs and transtages, then the mix of vehi- 
cles can vary within the run from all Centaurs to all transtages as the 
program moves year by year The statistics gathered for summation 
at the end of the run include the number in each class used m each 
year with a total over all years. The average number of expended 
upper stages is shown. If a vehicle is the uppermost from earth in the 
flight sequence, then its class gets credit for the delivery. The print- 
out shows the average flights and average total payload weight delivered 
to each orbit by each class. If the program is used with small fleet 
sizes, flight delays are associated with the class of vehicle by showing 
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the average delay for when no vehicle was available for a flight and the 
percentage of unavailability in each class of vehicle. 

2. 2. 2 Vehicle Modes of Operation 

The Shuttle is used to deliver Shuttle-only payloads 
and payloads requiring the additional performance of an upper stage. 
For the Shuttle-only flights, the program checks end-to-end packed 
payloads against the weight and length constraint for the deploy mode 
only. The down payload traffic is not checked. 

The upper stage vehicle can be composed of one to 
three stages which can be combinations of expendable, reusable, 
solid, or liquid stages. However, the combination of expendable 
lower stages with reusable upper stages is not permitted nor can 
solid lower stages be combined with liquid upper stages. 

The program takes a payload group, determines a 
delivery sequence including phasing maneuvers, and delivers the 
list of payload weights with corresponding d Vs to the performance 
computation routines These routines use the simple rocket equation 
to compute the propellant requirements by processing the list in 
reverse order, resulting in the total propellant required and the 
total weight of the vehicle, including payloads and propellant. The 
propellant required is constrained by input to a maximum value, and 
the gross weight of the vehicle is constrained by the Shuttle capability 
The end-to-end packing of payloads on the front end of the upper stage 
IS constrained to a value that permits the upper stage to fit in the Shut- 
tle bay with the payloads 

The program operates on a fly-on-demand basis and 
does not support multiple payload- vehicle combinations in the Shuttle 
bay nor does it support the concept of two Shuttle flights for a tandem 
Tug with payload and on-orbit docking. The only on-orbit activity 
permitted is the separation of payload (maybe with upper stage) and 
rendezvous with a returning upper stage with payload. 
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2. 2.3 


The SEPS Vehicle 


A portion of the program is intended to perform deploy- 
ment, servicing, and retrieval missions to synchronous equatorial orbit 
using a Tug-type upper stage with a continuous low-thrust upper stage 
known as a Solar Electric Propulsion Stage (SEPS). The SEPS ferries 
payloads back and forth between an intermediate orbit and synchronous 
orbit and performs the necessary servicing maneuvers in synchronous 
orbit. The Tug carries payloads between the Orbiter and the intermed- 
iate orbit, deploys fully fueled SEPS vehicles, and retrieves exhausted 
SEPS vehicles when and if required. The SEPS is assumed to operate 
in the ground-based mode, that is, the SEPS is initially launched with a 
specified amount of fuel, and, when that fuel is exhausted (or nearly so), 
the SEPS IS either returned to earth for refurbishment or abandoned in 
space. In this usage, the time and fuel remaining on a SEPS vehicle are 
monitored, and Tug flights are automatically initiated to launch new SEPS 
vehicles as required and return expended ones, if required. Missions 
which are found to be within the capability of the Tug alone are performed 
without the aid of SEPS, and payloads which cannot be boosted to a circu- 
lar orbit of at least 8000-nmi altitude by the Tug are not launched, since 
the SEPS is not allowed to operate in the region of the Van Allen radiation 
belts (due to rapid solar cell degradation). 

This feature is not fully operational at this time. For a 
description of the equations and logic, see Aerospace Report No. 

ATR-74 (7341)-2, Operations Analysis (Study 2. 1), Program Sepsim 
(Solar Electric Propulsion Stage Simulation ), by T. F. Lang. 

2.2.4 The Phasing Algorithm 

The Tug is currently being designed to have an on-orbit 
life of seven days, which is a fixed constraint The phasing algorithm 
attempts to provide service at several different points spaced around the 
orbit but always in the seven-day time frame by controlling the A V 
required for the individual transfer orbits Thus, a typical trajectory 
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sequence would be an ascent, one or more phasing maneuvers, and a 
descent Of course, there are sequences without phasing maneuvers 
or the descent trajectory. The procedure for computing the phasing is 
divided into two parts. The phasing sequence is described in the writeup 
on the Subroutine PASER in the Programmers Manual The for the 
transfer orbit from one orbit position to another is done iteratively, posi- 
tion by position 


n 



D + 0 Z 

r 


where n is the number of revolutions in the transfer orbit (n > o) 
a IS the 1 ^^ phase angle, 

T^ IS the total of the remaining phase angles, and 

is the number of days remaining to phase through T. 
The 0, 2 IS a rounding adjustment more or less empirically derived. 


1 - 


360 n 


where P^ is the period of the transfer orbit P or P^ > P). 


P IS the period of the basic orbit 


T 

P 


n 


where T is the flight time for the phasing maneuver with no allowance 

P 

for rendezvous 


The time remaining is reduced by T 


P’ 


and if D — 
r 


0. 5 
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days, the flight is declared unfeasible because of the 7 -day time con- 
si raint If < 0.3535 P, the flight is declared unfeasible because 
the transfer orbit is impossible. 

2/3 

- 1 ) 



where is the perigee radius of the transfer orbit, 


R IS the apogee radius of the basic orbit 
3 


R 


V = V 

cp CO 


R 


pt 


where is the perigee velocity of the transfer orbit, 

IS the equivalent circular velocity of the basic orbit, and 


R^ IS the equivalent circular radius of the basic orbit. 


Then 



This series of expression equations is done for each 
position in orbit, and the result is a series of 4 Vs or the sequence 
IS not feasible in the seven-day constraint. 


2-16 



2.2.5 


The Loading Queue 


When a new satellite arrives at the launch facility, 
it IS entered into a loading queue for subsequent scheduling of a flight. 
The loading queues are ranked by time, thereby assuring that earlier 
payloads in the queues are the first ones to be flown. Each loading 
queue IS destined for a specific orbit. The program logic does not 
support a multi-transfer orbit sequence but rather makes a direct 
ascent to the orbit and then performs phasing maneuvers within that 
orbit. Therefore, performance computations are restricted to that 
queue designated for a specific orbit, 

A loading queue is permitted to fill up as a rationale 
of increasing the upper stage load factor t>. The criteria for emptying 
the queue are 

a. When a payload is put into the queue, all payloads in 
the queue are flown by the performance routines on 
a trial basis If the flight is possible, the queue is 
placed in a flight-ready state If the flight is not 
possible, the previous group of payloads {which the 
program remembered) is flown immediately, if the 
required vehicles are available This removes some 
of the payloads from the queue. If the vehicles are 
not available, the queue remains in the flight-ready 
state 

b. When a payload is put into the queue, a mandatory 
launch event is scheduled for 90 days later. (The 

90- day period is an input parameter. ) When the man- 
datory event occurs at the end of 90 days, the loading 
queue is checked to see if the payload is still there 
If so, the payload is scheduled to be flown with all 
other similar waiting payloads based on vehicle per- 
formance computations. This usually results in 
emptying the queue. However, if the vehicles are 
not available, the payloads m the queue will wait. 

c. When a vehicle completes its refurbishment cycle, a 
check IS made of payloads waiting for vehicles. The 
first group of payloads for which all vehicle elements 
are suitable will be flown. The queue may or may 
not be emptied, depending on the circumstances. 
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A Sortie payload is treated differently. When a Sortie 
arrives, there is no wait unless a vehicle is not available. Sortie pay- 
loads fly alone always, but Sortie payloads can be in the queue with 
other payloads, however, the other payloads will be ignored when the 
Sortie is in the queue 

The LOVES Program attempts to launch all payloads, 
even if it is necessary to expend reusable vehicles to deliver payloads 
too heavy to deliver in a reusable mode. The increased deployment 
capability in the expend mode is used to fly a higher payload weight than 
normal, and other payloads are included in the flight. No retrieved pay- 
loads are flown in this flight, but modules plus service units are carried 
and expended 

2.3 PROGRAM DATA FLOW 

2.3 1 Input Data Formats 

The data input to the LOVES Program consists of two 
parts. The first part is what is referred to as SIMSCRIPT initialization 
data which define the sizes of the arrays used by the program and input 
some simple constants. The second part of the input provides the data 
for vehicles, orbits, modules, satellites, satellite systems, determinis- 
tic launch schedules, and scheduled mission equipment upgrades. The 
complete deck setup is shown in Figure 2. 

Data formats can be summarized as alphabetic entries 
which are left justified and integer entries which are right justified 
Numerical entries containing decimal points must be written with the 
decimal point in the correct column. 

The two EQUIP cards (see page C-5) are required for the 
GDC systems but are not used on the UNIVAC 1108 systems 

The first physical card of the deck is the Run Parameter 
card. This card does not change unless a new variable is added to the 
program with an array number greater than 285. Then the value 285 
must be increased to the new value. 
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Figure 2. Configuration of Input Data Deck 


2.3.1. 1 


Initialization Deck 


The initialization deck is sometimes referred to as the 
"front end." It is a relatively static deck, changing only when the sim- 
ple constants are changed in parameter sensitivity studies and when the 
model grows by the addition of new modules, satellites, etc., to the 
data deck such that the amount of memory must be increased. 

The front end card is defined as follows 


Columns 


Data Description 


2-4 

6-8 


10 


12 

13 


16 - 18 


19-22 
50 - 66 


The array number for variables (as defined in 
Appendix B) which are input in strict numerical 
s equenc e . 

A second array number whose presence implies a 
first array number through and including the second 
array number. 

Dimensionality of array numbers. This entry is 
either 0 or 1 and must be as shown in Appendix C 
(C-5 and C-6). (It is checked against the defini- 
tion portion of the program code. ] 

Read column is either blank or R. An R implies 
data in columns 50 - 66. 

Zero entry column is either blank or Z. These 
two columns 12 and 13 must have one entry between 
them to stipulate a read or 0 operation. A Z will 
preset memory to 0. 

An array number previously defined by a read-in 
card. This states which variable has the dimen- 
sionality constant for these arrays. These columns 
are used for dimensionality of 1 (column 10). 

A four-digit vector length constant which must agree 
with the value input into the array number refer- 
enced in columns 16 - 18. 

Numerical inputs except the format 7 (A6) which 
should be left alone. The numerical values can 
be anywhere in these columns and must have or 
have not the decimal point as shown. If the deci- 
mal point IS left out, the value is an integer which 
is quite different from a value with a decimal point 
The value would be very near 0. 
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67 - 80 


Commentary area used to associate names with 
array numbers. 


The front end deck is terminated by a blank card. 

2. 3. 1.2 Event Card 

The event card is used to trigger the simulation and 
contains two data entries, the start and stop times of the run. The 
structure of an event card is 


Columns 

Name 

Data Description 

1 - 2 


Blank 

3 


1 

4-13 


Blank 


14 - 23 

TIMEB 

Year, month, and day with the decimal 
point in columns 18 and 21. Month 0, 
day 0 - January 1. 

24 


Blank 

25 - 34 

TIMES 

Year, month, and day with the decimal 
point in columns 29 and 32. 


1-2 

3 

4-13 

14-23 

24 

25-34 


1 


TIMEB 


times 


18 21 29 32 


The remainder of the data deck consists of groups of 
data in the form of tables describing vehicles, orbits, modules, satel- 
lites, satellite systems, satellite launch schedules, and mission 
equipment upgrade schedules 
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2.3. 1.3 


Vehicle Data 


The first group of data cards is for vehicle data. The 
structure of the first card is 

Columns Name Data Description 

1-3 COUNT The right justified count of the number 

of different vehicles available to the 
program. This entry will be referred 
to as an 13 format for later groups of data. 



The data description of each vehicle will occupy one 
vehicle card The format of the card is fixed and applies equally to 
Shuttles, upper stages, and SEPS vehicles. The actual type of each 
vehicle is determined by its usage in the orbit table that follows the 
vehicle data. The structure of a vehicle data card is 


Columns 

1-6 

7-13 
14 - 20 


Name 

NAMEV 

DAYSV 


ISP 


Data Description 


The alphabetic name of the vehicle. 

For the SEPS, the only name of the 
vehicle is SEPS. 

The maximum total flight time of the 
vehicle in days including phasing 
maneuvers with the decimal point in 
column 12, 


For the SEPS, this entry is the maxi- 
mum thrust time in days. 

The effective specific impulse of the 
vehicle in seconds with the decimal 
point in column 19. 
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Column 


Name 


Data Description 


21 - 27 
28 - 34 

35 - 41 


42 - 48 


49 - 55 
56 - 62 


63 - 64 


65 - 66 


WDV 

WPNUV 

WCONV 


REFTV 


EXPV 

PAYLV 


NSTAG 


SOLID 


The burnout weight of the vehicle in 
pounds with the decimal point in column 26. 

The non-useable propellant of the vehicle 
in pounds with the decimal point in column 33 

For the SEPS, this entry is the reserve pro- 
pellant in pounds 

The gross weight in the Shuttle in pounds 
with the decimal point in column 40. For 
an upper stage, this is the maximum pro- 
pellant available in pounds 

For the SEPS, this entry is the power level 
in watts 

The refurbishment cycle time of the vehi- 
cle in days with the decimal point in column 
47 

For the SEPS, this entry is the weight of the 
usable propellant 

If it IS not 0, the vehicle is to be expended. 
The decimal point is in column 54 

The maximum length of stacked payloads 
that can be put on top of the vehicle. For 
the Shuttle, it is the available length of 
the payload bay The entry is in feet with 
the decimal point in column 61. 

For the SEPS, this entry is the percentage 
propulsion efficiency. 

The number of stages of a multistage vehi- 
cle. The data cards are ordered Stage 1, 
followed by Stage 2, followed by Stage 3 
(if any). 

If it is not 0, the stage is a solid. 
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l - 6 

7-13 

14 - 20 

21 - 27 

28 - 34 

35 - 41 

42 - 48 

49 - 55 

56 - 62 

63 - 64 

65 - 66 

NAMEV 

DAYSV 

ISP 

WDV 

WPNUV 

WCONV 

REFTV 

EXPV 

PAYLV 

NSTAG 

SOLID 


12 

19 

26 

33 

40 

47 

54 

61 




The number of vehicle cards must agree with the vehicle 
count on the first card. A stage is considered a vehicle and can be used 
as the second stage of a two-stage vehicle and as a separate vehicle in 
its own right 

2.3. 1,4 Orbit Data 

The next grouping is for orbit data. The structure of the 
first card is the same as that of the first card of the vehicle grouping, 

1 . e. , the count of orbits is in the 13 format. 

The data for each orbit will occupy one orbit card. The 
structure of an orbit data card is 


Columns 

Name 

Data Description 

1-6 

ORB ID 

The alphabetic name of the orbit. 

7-13 

ORBDV 

The AV required to go from the parking 
orbit into the final orbit (two-burn mini- 
mum) with the decimal point in column 12. 

14 - 20 

f 

ORBPD 

The period of the orbit in hours with the 
decimal point in column 19. 

21 - 27 

ORBRA 

The apogee radius of the orbit in nauti- 
cal miles with the decimal point in 
column 26. 

28 - 34 

ORBVC 

The eqmvalent circular velocity of the 
orbit in feet per second with the decimal 
point in column 33. 

35 - 40 

RQUP 

The alphabetic name of the required upper 
stage, if any. 

41 - 46 

RQSEP 

The alphabetic entry SEPS if the SEPS 
vehicle is to be used. 
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Column 


Name 


Data Description 


47 - 52 RQSUT The alphabetic name of the Shuttle 

assigned to deliver to parking orbit 

53 - 59 DVI The 4V for the first burn of the tran- 

stage with kick solids with the decimal 
point in column 58 


1-6 7-13 14-20 21-27 28-34 35-40 41-46 47-52 53-59 


NAME 


DV Period 


12 


19 


R 


26 


V 


33 


RQUP 


RQSEP 


ROSUT 


DV. 


58 


The number of orbit cards must agree with the orbit 
count on the first card. 

2. 3. 1.5 Module Data 

The next grouping is for the data pertaining to mod- 
ules The first card of the group is the count of modules in 13 format, 
and the warning factor FACT is in columns 4-8 with the decimal 
point in column 5. 


1 

2 

3 

4-8 

9 - 80 

j 

1 


FACT 

4 

Not Used 


5 


Then the individual module cards are entered, one card per module. 
The number of cards must agree with the input count of modules. The 
structure of a module card is 
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Columns 

Name 

Data Description 

1 

- 6 

MNAME 

The alphabetic name of the module. 

11 

- 15 

ALPF 

The Weibul failure parameter with the 
decimal point in column 13. 

16 

- 20 

BETAF 

The Weibul failure parameter with the 
decimal point in column 18. 

21 

- 24 

TTFMD 

The module truncation time with the 
decimal point in column 24 

25 

- 30 

MODWT 

The module weight in pounds with the 
decimal point in column 30. 

31 

- 35 

MDVOL 

The module volume in cubic feet with the 
decimal point in column 34. 

36 

- 41 

MCLAS 

The alphabetic module classification. 

45 

-49 

ALPW 

The Weibul warning parameter with the 
decimal point in column 47 If this 
entry is 0, it is replaced by ALPF^FACT. 

50 

- 54 

BETAW 

The Weibul warning parameter with the 
decimal point in column 52, 

55 

- 57 

R 

The reliability (90. ) for the module with 
the decimal point in column 57. 

58 

- 62 

TAU 

The period of time at which R is true 
with the decimal point in column 60. 


1 - 10 11 - 15 16 - 20 21 - 25 26 - 30 31 - 35 36 - 41 45-49 50-54 55-57 58-62 


Name 


4 

CM 

WT 

Vol 

Class 

« 

u 


R 

r 




■■ 





• 

• 



13 18 24 30 34 47 52 57 60 


The number of module cards must agree with the module count on the 
first card 
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2.3 1.6 


Satellite Data 


The next grouping is for satellite data. The structure 
of the first card is the same as that of the first card for the vehicle 
grouping, 1 . e., the count of satellites in the l3 format. 

The data for each satellite will occupy three or more 
cards per satellite. The first card for the data for a satellite is 


Columns 

Name 

Data Description 

1 - 10 

SNAME 

The alphabetic name of the satellite 

11 - 15 

SWT 

The unused satellite weight in pounds 
with the decimal point in column 15. 

16 - 20 

SVOL 

The satellite volume in cubic feet with 
the decimal point in column 18. 

21 - 25 

PRIOR 

The satellite pri ority with the decimal 
point in column 25. 

26 - 30 

INCL 

The orbit inclination with the decimal 
point in column 30. 

31 - 36 

ORBIT 

The alphabetic name of the orbit. 

37 - 70 

Unused. 


71 - 75 

NMOD 

The integer count of the number of 
modules comprising this satellite. 

16 - 80 

TTSAT 

The termination time of the satellite 
with the decimal point in column 80. 

1 — 10 11 

— 15 16 — 20 21 

— 25 26 — 30 31 — 36 37 — 70 71 — 75 76 


— 

Name 

wt 

Vol 

Pr 

1 

Orbit 

1 SPARE 

NMOD 

T 

s 


15 18 25 30 
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The second card of a satellite group is 


Columns Name Data Description 

1 POLDN The policy (1, 2, 3, 4) for replacing the 

satellite on an NRU failure. 

2-6 SORTD If not 0, the payload is a Sortie to be 

aloft this many days. 

The remaining card or cards of the satellite group 
list the modules by name which the satellite comprises. The format 
of the module list card is 

Columns 1-10 are blank. 

The remainder of the card is divided into 7 fields of 
10 columns each. Each 10-column field contains a 6-column name of 
a module in the module table and a 4-column blank or nonblank entry. 

If the entry is 2 - 15, the module is the first member of a redundant 
group. The entry on the following module tells how many operational 
modules are required to call the group operational. If the four-column 
entry is otherwise not blank, the module cannot be replaced. Seven- 
modules may be entered per module card to provide the number of 
modules given in column 71 - 75 of the first card of the satellite group 
by entering the necessary number of cards. 


1 — 10 

11 — 19 

20 

21 - 29 

30 

31 — 39 

40 

41 . . . 

Blank 

Name 

1 

Name 

1 

Name 

1 



The number of groups of cards (each group is a satel- 
lite) must agree with the satellite count on the first card. 

2. 3. 1. 7 Satellite Systems Data 

The next group is for the description of the satellite 
systems. The first card in the group is the count of the satellite systems. 
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again in 13 format. Each system is described by one or more data 
cards. The structure of the first card for each system is 


Columns 

Name 

Data Description 

1 - 6 

SYNAM 

The alphabetic name of the system. 

7-11 

NFUP 

The integer number of active satellites 
required to have an active system (nine 
or less). 

12 - 16 

NS 

The integer number of satellites in the 
system (nine or less) 

17 - 20 

TTSYS 

The termination time of the system with 
the decimal point in column 19. 

21 - 30 

STNAM 

The alphabetic name of a satellite in the 
satellite group. 

31 - 40 

PHASE 

The longitude of the satellite with the 
decimal point in column 35. 

41 - 50 

STNAM 

The alphabetic name of the second satel- 
lite in the system. 

51 - 60 

PHASE 

The longitude of the second satellite 
with the decimal point in column 55. 

61 - 70 

STNAM 

The alphabetic name of the third satel- 
lite in the system. 

71 - 80 

PHASE 

The longitude of the third satellite with 
the decimal point in column 75. 


L—IO 11-1516-2021-3031- 40 41— 5051- 60 61 — 7071— 80 


Name 

^ 1 fr 

Name 

Long 

Name 

Long 

Name 

Long 


19 


35 


55 


75 


Should more than three satellites comprise a system, 
other satellites are entered on subsequent cards with the same format 
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except that columns 1-20 are blank. The number of satellite systems 
in put with one or more cards per system must agree with the count 
entered on the first card. The program has a limit of a maximum of nine 
satellites in a system. 

2. 3. 1.8 Satellite Launching Data 

The schedule of new satellite launchings is the next 
group of cards. Each card can designate up to four satellite launchings 
The card is, therefore, divided into 4 groups of 20 columns each. The 
20-column group is 


Columns 


Name 


Data Description 


1 

2-10 
11 - 20 


N The number of satellites in a satellite 

system. 

SYSNAM The name of the satellite system for 
which the satellite is intended. 

DATE The date of availability with the deci- 

mal point in column 15 and including 
the fractional part of the year. 


12 — 10 11 20 


N 


SYSNAM 


DATE 


15 


The schedule input is terminated whenever column 1 
of a card contains satellite number 0 of a system For user conven- 
ience, the program requires data in the first 20 columns, the others 
are optional 
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2.3 1.9 


Mission Equipment Upgrade Data 


The schedule of launching of mission equipment 


upgrades is the next group of cards. Each card can designate only 


one upgrade. 

The structure of 

a card is 

Columns 

Name 

Data Description 

1 - 6 

SYNAM 

The name of the system containing the 
mission equipment to be upgraded. 

7-10 

NS 

The number of the satellite in the 
system. 

11 - 16 

MEOLD 

The name of the old module. 

17 - 20 

NM 

The number of duplicates to be replaced. 

21 - 30 

Date 

The date at which the new modules 
become available. The entry is of 
the form, 1984. 01. 01 for year, month, 
and day. The decimal points are in 
columns 25 and 28. 

31 - 36 

MENEW 

The name of the new module intended to 


replace the old one. 


1 - 6 

7-10 

11 - 16 

17 - 20 

21 - 30 

31 - 36 

37 - 80 

SYNAM 

NS 

MEOLD 

NM 

Date 

MENEW j 

Not Used 


25 28 


The upgrade input is terminated whenever column 1-6 
of a card contains a blank system name. 

2.3.2 Naming Conventions 

All names input into the program are restricted to 
SIX characters in length Some naming conventions used in other 
applications are cited as examples for the user 
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VEHICLES 


ORBITS 


MODULES 


TUG and XTUG for the Tug to be used 

in the reusable mode versus the 

expended mode. 

SHUTLl, SHUTL2, etc. to define the 

Shuttle performance to different altitudes. 

SEPS IS reserved for the said vehicle. 

SYNC/0 - Synchronous, equatorial. 

100/35 - 100 nmi circular, 35-degree 

inclination. 

1-2/30 - 100 X 200 nmi, 30-degree 

inclination. 

ESCl - Interplanetary injection 
orbit No, 1. 

AVCSl, AVCS2, etc. for altitude control 
modules. 

EPSl, EPS2, etc. are electrical power 
modules. 


SATELLITES ASTIC, EOP4, NNDIA, NNDIB are satel- 
lite designations found in the current mis- 
sion model shortened to six characters 
and using the letters A and B for different 
versions. 


SYSTEMS Systems names usually match the name of 

the satellite members or the name of the 
program, agency, or whatever - NNDIAB, 
COMSAT, EOL, SURV, EARTH, etc. 


The name SEPS is the only reserved name in the program, 
all others are at the discretion of the user. The user is reminded to avoid 
duplicate names in the input tables, as the program will tend to ignore the 
duplicate name occurring after the first definition. 

2, 3. 3 Input Data Errors 

The computer code will detect three classes of errors* 
mispunched data cards, invalid dimensioning, and an invalid model 

2. 3. 3.1 Mispunched Data Cards 

The SIMSCRIPT system requires that the decimal point 
be in the column stipulated by the code. This is the most frequent error 
made by a user, misalignment of data entries. In such cases, the message 
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generated is unfortunately insufficient as it identifies the routine 
detecting the error and little more. The user must then look at a 
listing of the data cards and visually locate the misalignment An 
impatient user can look at the output of the program (■which also 
shows the input data) and, by a careful perusal, with intelligence, 
deduce the errors The following list of routines with the name of 
the data table they process may be an aid to error detection 


LDVEH 

LDORB 

LDMOD 

LDSAT 

LDSYS 

LDSCH 

LOME 


Vehicle Data 

Orbit Data 

Module Data 

Satellite Data 

Systems Data 

Satellite Launch Schedule 

Mission Equipment Upgrade Schedule 


Errors of this type can cause other errors later. 
Therefore care is required in diagnosing subsequent errors (especially 
nearby). 


2. 3, 3. 2 Invalid Dimensioning 

For example, the vehicle data may be preceded by a 
number that states the number of vehicle cards being input. The pro- 
gram checks the number against the value intended into array number 
85, and, if it is greater, an error message will be printed. The solu- 
tion IS to increase the value in array number 85. 

2. 3. 3. 3. Invalid Model 

The user can make errors in his model by referencing, 
for example, a module by a name that is misspelled or doesn't exist in 
the module data. The program will identify the erroneous entry, and 
the user will have to figure out what he intended to do. This is the 
only checking done, the consistency and content of the model are the 
responsibility of the user. Three clues for inconsistency of the model 


2-33 



are: no satellites ever initially launched to a particular orbit position are 
shown as a 0 in the total launched for that position, bad satellite launch 
schedules are shown by satellites becoming available after the system goes 
permanently disabled (NG) or by high maximum delays and low minimum 
availabilities 

2 3 4 Program Output 

This section describes the computer output in Appen- 
dix C beginning on page C-5. The printout logically separates into the 
following groups of pages listed in order of occurrence. 

2. 3.4. 1. Initialization Cards (Pages C-5, C-6) 

This IS an exact line for line copy of the front end portion 
of the input deck with header lines of card column numbers The first 
card with the series of numbers (285, 30, 12, etc ) is the specification 
card and should be left as is The remaining cards comprise the front 
end including the blank terminating card. 

2. 3.4. 2 Input Data (Pages C-7, C-8) 

This IS a print back of the input data deck with reformat - 
mg of the data. In producing this printout, a modification was made to 
the routine LDMOD to force the module termination time to be 20 
years (which reduced the output because no modules were terminated). 

2. 3.4. 3 Synopsis of Input (Page C-9) 

As the launch schedules were read in, the systems 
were tagged as being in use. Therefore, the program detected an 
unused system in the input. The user must decide on the criticality 
of the message, since an unused item consumes memory. A check was 
made by computing the necessary satellite/ system position needed by 
the launch schedules, and that value is printed with the front end entry 
in array number 230 (which offers a potential savings in memory). The 
number of required systems is printed with the entry in array number 
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200, The unused satellites are listed, and the number of required satel- 
lites IS printed with the entry in array number 180. The unused modules 
are listed, and the required number is printed with the entry in array 
nvtmber 150, 

2. 3. 4. 4 Chronological Time History of Base Cycle (Pages C-10 

through C-12) 

As the program executes the first cycle from year 1 to year 
3000, this printout is produced showing all events as they occurred. The 
column titles are Time in years, months, and days with clock counting 
from zero (January 1, 1980=1980. 0,0), system name with operational 
status, module name with operational status, satellite name with opera- 
tional status, and vehicle name and number with availability status. The 
small number after the system identifiers the member of the system, which 
IS necessary if the same satellite is used several times in the system. Tor 
instance, the user might read, ”on 1980.3.28, the satellite NNDIA became 
available for launch " It is the third member of the inoperative system 
NNDIAB. On 1980.3.28, a launch of Shuttle 20 and Tug 10 occurred, 
because the Tug could not carry both payloads All payloads listed 
between "launch now" and the dashed line were launched together. On 
1980. 3. 29. the satellite NNDIA is placed in operational mode at its orbital 
position. On 1980,4. 14, Shuttle 20 and Tug 10 completed xefurbishment 
and became available for use again On 1980 7. 22, the module TTCl 
failed, causing the satellite NNDIA and the system NNDIAB to be inoper- 
ative. The module was replaced on 1980. 9. 2. In this sample, there are 
launches occurring because of exceeding vehicle performance (1980.3. 28 
twice) and mandatory after 90 days (1980, 8. 26-NNDIB). These are 
launches of single- and multiple -satellite deployments (1983. 2. 27) and 
multiple-module replacements with a definite delivery sequence 
(1982.6. 18). There is an instant launch of a Sortie (1982. 1. 2) with its 
subsequent return after seven days in orbit. For each launch, the total 
payload weight and length including service units are shown. At the 
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end of the cycle, all satellites are operationally terminated and left 
in orbit. Five days later, the last Shuttle and Tug complete refurbish- 
ment, This printout is used to verify the interactions between the 
events and to show difficulties in the mission model of too small a 
fleet, forced expenditure of a vehicle, or excessively overweight payload. 

2. 3.4. 5 Chronological Time History of Satellite Position in 

Orbit (Page C-13, C-14) 

This IS a rearrangement of the preceding report with the 
vehicle and launch information deleted. The information is arranged so 
as to provide a history of all activity pertaining to a specific satellite at 
a specific orbital position. Thus, the user is informed about the birth, 
life, and death of each satellite. The user can trace the system activity 
as all members of the system are grouped together, yet separately. 

2. 3, 4. 6 Statistical Summary for 25 Monte Carlo Cycles (Page C-15) 

Between this page and the preceding page, the program has 
executed but not printed 24 additional cycles, none of which were identical 
to any of the others. This is effected by the use of a random number gener- 
ation which can be negated by the variable TIMEC. This page is the flight 
summary for the three classes of vehicles Shuttles, upper stages (called 
Tugs), and the SEPS. For example, in the year 1982, the Shuttle flew a 
minimum of 2 flights on one of the Monte Carlo cycles, averaged 3. 2 flights 
over all cycles, and flew a maximum of 5 flights on another Monte Carlo 
cycle. The Tug flew one less flight in that year because the Sortie operates 
on the Shuttle only. The totals of all years are computed for each Monte 
Carlo cycle, and the values obtained are used to determine the minimum, 
average, and maximum total flights. The user is cautioned against attempt- 
ing to add the minimum or maximum columns for a check, i. e,, the sum 
of the mimmums is not the minimum of the sums. The other two lines are 
connected with vehicle availability; percentage of time the vehicle was 
unavailable and the number of delays in days resulting from vehicles being 
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unavailable This sample had a very large fleet and therefore did 
not suffer any shortages of vehicles There is one more line show- 
ing the average number of expended upper stages which is 0 in the 
sample (suppresses printing of line). Note that the SEPS was not used 
in the run 

2,3.4 7 Orbit Traffic Summary (Page C-16) 

This report quotes the average number of flights and 
average delivered payload weights for each orbit separately. For 
example, the Tug made the final delivery to the orbit SNC/O with 
11.7 flights and 3179 pounds per flight The 11 7 agrees with the 
previous page. There is no traffic to the orbit 1-1/28 The Shuttle 
delivered the 10, 000-pound Sortie once each cycle to the orbit SORT 
for an average Shuttle load factor of 16 percent. 

2 3 4 8 Statistics for System - ASTID (Pages C-17 

through C-20) 

This report summarizes the statistics for each module on 
each satellite, each satellite in each system, and each system The system 
name appears as above The modules for the satellites in the system are 
summarized individually For example, the first AVCS7 module was re- 
placed a maximum of once in the 25 cycles The average count is too small 
to show, and the maximum of 1 required a maximum of 0 25 equivalent vehi- 
cle flights (the maximum of 1 could have occurred 5 or 6 times) The first 
Astronomy ID Satellite was deployed exactly once m each Monte Carlo cycle, 
yielding an average of 0 49 equivalent flights in a band from 0 40 to 0 76 
Including the module flights, this yields an average of 0 77 flights flown in 
support of this satellite The satellite was operational or available 85 05 per- 
cent of the time and averaged 6l 93 days of outage during the 25 cycles The 
second Astronomy ID Satellite of the system is shown, and, in this case, 
the system statistics are also shown The system required a minimum of 
0 88 Tug flights but suffered operationally as badly as approximately 30 to 


2-37 



75 percent, while it took a minimum of 2 99 days to restore the system to 
service. It is very likely that the three values did not occur in the same 
cycle, particularly since there was one cycle in which the system was fully 
operational A dash line indicates the end of the statistics for a system 

2-3 4. 9 Module Summary (Page C-21) 

This report summarizes the warning, failure, and replace- 
ment activity of each module m the original module table For example, 
the module AVCS7 is a frequently used module, appearing 24 times in the 
previous report The module had no warning mechanism but failed an aver- 
age of 39 times per Monte Carlo cycle in a band of 2 to 8 But an average 
of 3 5 out of 4 were replaced as modules failing too close to satellite, sys- 
tem, or run termination The module MODULiE has no failure mechanism, 
and NAS TIC is too reliable (long lived) to have failed 
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3 PROGRAMMERS MANUAL 


Tills section is provided as documentation for the LOVES 
Computer Program Code and as a convenient reference should the need 
arise to modify the code or the basic procedures in the program. It will 
also provide further understanding for the user who takes the time to 
peruse this part of the document 

The section is divided into three parts First is a descrip- 
tion of the SIMSCRIPT 1 5 part of the program with detailed definitions for 
each event and subroutine The second part provides detailed definitions 
of a group of subroutines coded in FORTRAN and used to pass data along 
into labeled common areas for the FORTRAN coded performance subrou- 
tines The third part of the section includes a general description of the 
performance computation subroutines, also in FORTRAN Following this 
section are supporting appendices which describe and illustrate each set 
and queue (Appendix A) and each of the variables defined globally in the 
program (Appendix B) 

A series of flow charts are provided in Figures 3 through 
5 which illustrate how the LOVES Computer Program is linked together 
and the interconnections between the various events and subroutines The 
connections (or calls) to subroutines are shown by the solid lines, and the 
connections marked by the dashed lines indicate which events and subrou- 
tines initiate other events The events are differentiated from the sub- 
routines by asterisks following each event name 

Figure 3 is divided into an input section and a Monte 
Carlo section. The input section is executed only once at the beginning 
of the run The Monte Carlo section contains the event START to initiate 
the Monte Carlo cycle and the event TERM to terminate the cycle. The 
other subroutines have to do with the chronological printout of all activity 
for the first cycle only for each individual satellite, the gathering of sta- 
tistics at the end of each cycle, and the final statistical output (TERMO). 
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The heart of the simulation is illustrated in Figure 4, 
beginning with the events START and NWSAT This section of the 
simulation is concluded with the subroutine PROP which is the transi- 
tion to the next illustration (Figure 5) Figure 4 is extremely complex, 
and the most important point in this phase of the simulation is not 
readily apparent from the diagram--most of the activity flows through 
or around the two subroutines SHIP and STATUS, 

The subroutines shown in Figure 5 are all coded in 
FORTRAN except for the transition subroutine PROP. All of these 
subroutines have to do with vehicle performance and phasing considerations. 

3. 1 ELEMENTS OF SIMSCRIPT 1.5 

3. 1. 1 Overall Logic Construction 

A simulation program written in SIMSCRIPT has no 
main program per se The SIMSCRIPT simulation system provides 
the main program for the user and consists of subroutines and events. 
SIMSCRIPT subroutines are programmatically identical to FORTRAN 
subroutines with parameter lists and return statements, and FORTRAN 
subroutines can be called from SIMSCRIPT routines Events are routines 
called by the SIMSCRIPT system, and they are divided into two classes 
external events (exogenous) and internal events (endogenous). External 
events are triggered by a card in the input data deck, and internal events 
are set up and triggered by the code of the various events and subroutines. 

An event differs from a subroutine in that an event occurs 
or IS called at a specific time on the simulation clock. At the completion 
of an event, control is passed back to the mam SIMSCRIPT subroutine 
which finds the next closest event in the immediate future That event 
then occurs or is called. 

This program consists of one external event (used to 
start the simulation) and 15 internal events for the simulation, including 
start and stop events. The program does a simulation between the bounds 
of the start and stop events which is repeated n times in a Monte Carlo 
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Figure 3 The Input Section and Monte Carlo Control Section 

























Figure 4. Monte Carlo Cycle Area, Heart of the Simulation 


















































fashion. Each cycle is different according to the random sequence out- 
put by a random number generator. 

SIMSCRIPT also provides the capability of processing 
waiting lines (referred to as queues, holding queues, or sets). Queues 
can be first in-first out (supermarket checkout lines), last in-first out 
(stack of plates), or ranked in ascending or descending order Queues 
are more fully discussed in Appendix A. 

3.12 Definition Table 

The first part of a SIMSCRIPT program is the Defini- 
tion Table in which variables, events, entities, and attributes are 
defined, typed, and dimensioned. The format of the cards in the defini- 
tion table can be found in the SIMSCRIPT manual The variables, etc. 
listed on these cards are retained by the compiler as it processes the 
remainder of the program Thus, these variables, etc. are accessible 
by any SIMSCRIPT routine A more exact definition of these items can 
also be found in the appendices. 

3. 1 3 Events List 

The events list begins with the word "EVENTS, " and 
then informs SIMSCRIPT which events are external (exogenous), which 
are internal (endogenous), and the number of each In this program, 
there is one external event BEGIN which is keyed as number 1. The 
digit 1 appears on the event card in the data deck requesting the SIM- 
SCRIPT event- sequencing routine to execute event 1 (BEGIN) at the 
time entered on the card 

There is a list of 15 internal events These two lists 
(see Table 1) are used by the compiler to define the code for the event- 
sequencing routine The events list is terminated with an "END" card. 
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Table 1 Internal - External Events List 


INTERNAL EXTERNAL 

1 ARRIV L BEGIN 

2. BACK 

3. FAIL 

4 LAUNC 

5. NEWME 

6. NWSAT 

7. REFMO 

8. REFSA 

9 REFVE 

10. REMOV 

11. RZTRI 

12. SATDN 

13 start 

14 TERM 

15 WARN 

3.1 3 1 Event ARRIV 

This event occurs whenever a satellite or a module 
arrives at its destination in orbit If the payload is a satellite, the num- 
ber deployed and the number at the position are increased by 1 The satel- 
lite system and satellite clocks are started if necessary All the modules 
are activated, and the failure and warnings are predicted via the subroutine 
ADMOD If the satellite termination policy is not 0, the subroutine SAVER 
IS called for retrieval and new satellite delivery If the satellite is not a 
Sortie, the satellite termination event SATDN is set up. 

If the payload is a module, the satellite status is checked 
If it IS out, the subroutine returns The single module is activated by the 
subroutine ADMOD, and the module status line is printed by the subroutine 
STATUS. The number of times the module has been replaced is increased 
by 1 
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3. 1.3. 2 Event BACK 

This event occurs when a satellite is retrieved from 
orbit and actually reaches the ground The routine STATUS is used to 
print the line signifying the end of the retrieval operation in the chrono- 
logical summary printout. 

3. 1.3. 3 Event BEGIN 

This event is triggered by the event card in the input 
data deck, and the routine obtains the times TIMEB and TIMES from the 
event card Since the primary function of BEGIN is to initiate the simu- 
lation, it therefore sets up the first occurrence of the event START and 
calls the subroutine LDAT to load the remainder of the input data Time 
intervals input in days are rescaled to years, and the minimum variables 
of statistical parameters collected during the Monte Carlo cycles are set 
to arbitrary high values Control is then returned to the SIMSCRIPT 
system which will then cause the event START to occur 

3. 1.3. 4 Event FAIL 

This event occurs whenever a module fails as determined 
by the random number process used by the subroutine WEIBUL when the 
module was previously activated in orbit. If the satellite is out of service 
and must be replaced, the failure is ignored, otherwise the subroutine 
STATUS IS used to print the status line. The number of times this module 
has failed is then increased by 1. If the failure is too close to the end of 
life for the satellite, the failed module is not replaced, otherwise, a check 
IS made to see if a warning has occurred If so, the module is already 
scheduled to be replaced, otherwise, the module is entered into the load- 
ing queue and the mandatory launch event LAUNC is scheduled to force 
the payload to fly by a specified date 

3.1 3.5 Event LAUNC 

This event occurs at that time when a payload must be 
launched (mandatory launch event). The orbit for the payload is obtained. 
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and these data are used to scan the orbit queue to make sure the pay- 
load IS still in the queue If the payload is not in the queue, the event 
takes no action If the payload is still m the queue but there is no 
vehicle available, a message is printed, and statistics are collected 
on vehicle unavailability Otherwise, if the payload is in the queue 
and a vehicle is available, the subroutine SHIP is called to force 
the flight to go. 

3. 1 3 6 Event NEWME 

This event occurs when a mission equipment upgrade 
IS scheduled by input data The new module is put into the loading 
queue, and the subroutine STATUS is used to print the status line for 
"ME UPGRADE " 

3. 1.3. 7 Event NWSAT 

This event occurs whenever a complete satellite becomes 
available for launch The routine STATUS is used to print the status 
line for "AVAILABLE. " The routine will return if the arrival occurs 
after the system (to which this satellite belongs) has terminated its 
activity The satellite is scheduled for launch, and the mandatory 
launch event is set up under the conditions that the payload is not a Sortie, 
and the event does not occur after system termination 

3 1.3.8 Event REFMO 

This event is intended to occur when a module completes 
refurbishment The creation of the event elsewhere in the code has not 
been implemented, and the operations to be performed by this event have 
not been defined, 

3.1 3.9 Event REFSA 

This event is intended to occur when a satellite completes 
refurbishment The creation of the event elsewhere in the code has not 
been implemented, and the operations to be performed by this event have 
not been defined. 
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3.1.3.10 Event REFVE 

This event occurs when a vehicle completes refurbish- 
ment and IS thereby available again for a flight On the first Monte 
Carlo cycle, the vehicle refurbishment event is reported as a part of 
the chronological history The vehicle is identified as a Shuttle, Tug, 
or SEPS, and the appropriate fleet is checked for no vehicles avail- 
able. The refurbished vehicle is made available for use, if there were 
vehicles previously available, the event returns Otherwise the loading 
queues attached to each orbit are scanned to see if returning this vehicle 
to the fleet permits a pending flight to be launched The flight is launched 
via a call to the subroutine SHIP. 

3.1.3.11 Event REMOV 

This event occurs when the vehicle docks with a satel- 
lite being retrieved. The satellite is thus removed from service and 
from its orbit position at this instant. The subroutine STATUS is used 
to print the line in the chronological time history The subroutine QDMP 
is then used to remove any modules scheduled for replacement on this 
satellite from the loading queue if this is the only satellite at this position 

3. 1 3. 12 Event RETRI 

This event occurs when it is time to schedule in the 
loading queue the retrieval of a satellite The subroutine SHIP is used 
to put the retrieve request in the loading queue. There is no required 
time of completion, and therefore no mandatory launch event is set up. 

3.1 3.13 Event SATPN 

This event occurs when the lifetime of a satellite is 
reached At this time, the satellite is retired from service and can 
only be replaced by another satellite. The subroutine STATUS is used 
to print the line in the chronological time history 
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3. 1 3. 14 


Event start 


This event is first set up by the event BEGIN as the begin- 
ning of the first Monte Carlo cycle and thereafter set up by the event 
TERM for the beginning of a subsequent cycle For each satellite posi- 
tion in orbit and for each module assigned to each position, the statistical 
parameters to be accumulated over a Monte Carlo cycle are set to 0. If 
this is the first cycle, the chronological time history titling is printed 
The set NEWS (Appendix A) is processed to retrieve all the necessary 
NWSAT events as defined by the input data cards On the first cycle, 
the start simulation cycle event time is printed out The vehicle fleets 
are all placed in a state of availability The system statistical parame- 
ters to be accumulated are zeroed out The event TERM is set up for 
the arbitrarily chosen year 3000 (all events in the simulation will be done 
by then) The module statistical parameters are set to 0. 

3 1.3.15 Event TERM 

This event occurs at the end of each Monte Carlo cycle 
to provide a reference point for collection of statistics and a point for 
chosing whether or not to terminate or continue the simulation At the 
end of the first cycle only, the terminate simulation cycle event time is 
printed out and the subroutine FILEO is called. The Monte Carlo cycle 
counter TRIG (Appendix B) is advanced, and, at the end of each cycle, 
statistics are gathered by calling the subroutines MCVEH, MCMOD, 
MCSAT, and MCSYS. If the end of the run has been reached (TRIG 
^ TRIGS), the event calls the subroutine TERMO and stops Otherwise, 
time is set back to 0, and the event START is set up for the next cycle. 

3.1 3 16 Event WARN 

This event occurs whenever a module warns of an 
impending failure as determined by the random number process used 
in the subroutine WEIBUL when the module was previously activated 
in orbit If the satellite is out of service and must be replaced, then 
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the warning is ignored. If the satellite is in service, the subroutine 
STATUS IS used to print the status line, and the number of warnings 
for this module is increased by 1 However, if the warning is too 
close to the end of life for the satellite, the replacement module is 
not shipped. Otherwise, the module is put into the loading queue for 
shipment, and the mandatory launch event LAUNC is set up to force 
the payload to fly by a specified date 

3. 1 4 Subroutines List 

The following paragraphs describe the various individ- 
ual subroutines coded in SIMSCRIPT They have been arranged in 
alphabetical order for the convenience of the user 

3. 1.4. 1 Subroutine ADMOD 

This subroutine is called whenever an individual module 
is replaced on a satellite and for each module on a satellite when the 
satellite is presumed released from the delivery vehicle The purpose 
of the subroutine is to predict failures and set up a sequence of events 
for module failures and warnings from the module based on a random 
number input to the Weibul function The random number and the Wei- 
bul function are obtained from the subroutine WEIBUL 

In normal usage, the subroutine ADMOD is called with 
the parameters IS and IM where IS is the pointer to the specific satellite 
in an orbit position and IM is the pointer to the item MODSY in the 
queue Mod (Appendix A) identifying the specific module. The subroutine 
ADMOD IS divided into three logical sections or blocks of code 

a First, the module on the satellite is placed in an 

active state, the characteristics of the module are 
found, and the subroutine WEIBUL is used to deter- 
mine the predicted module warning time (TW) and 
failure time (TF), each a random interval of time 
from now into the future. 

b. The second section has to do with warnings Any warn- 

ing event associated with this module on this satellite. 
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IS removed from the timing queue If the variable 
TW IS 0, no warning events can be generated and the 
remainder of the section is bypassed. A warning can 
be detected either by telemetry data (random) or pre- 
dicted from known failure characteristics of the mod- 
ule less a lead time for delivery The minimum value 
of the two IS taken to predict the event The event 
cannot occur after the predicted termination of the 
satellite The event is defined and entered into the 
timing queue, and its location in the timing queue is 
recorded in the module data of the satellite for later 
reference 

c. The third section deals with the pending failure of the 

module. The processing for a failure is identical to 
that of a warning except there can be no lead time on 
a failure that can occur any time up to termination of 
the module, 

3 1.4.E Subroutine CSPAY 

This subroutine computes the statistics associated with 
the launching of a set of payloads, and it is called from the subroutine 
ISSUE. For each payload scheduled for the current flight, the following 
functions are performed 


a 


b 


c 


3. 1 4.3 


The total payload weight of the flight is accumulated, 
and, if the payload item is a module, the number of 
times the module is flown is increased by 1. 

The number of service units (each holding a number of 
modules) is determined, and the weight of the service 
units IS added to the total weight and prorated equally 
among all the modules on the flight 

The weight factors (individual payload weight divided by 
the total weight on the vehicle) are accumulated for the 
total traffic to a satellite position, the total traffic of 
whole satellites only to a satellite position, and the total 
traffic for each module at each satellite position 

Subroutine DROPQ 


The function of this subroutine is to remove a payload 
from the orbit queue and the loading queue The subroutine DROPQ is 
called with the parameters J and lO where J is the pointer to the payload 
in the loading queue and lO is the pointer to the orbit being processed. 
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The orbit queue is searched, and, when the payload is located, it is 
deleted from both the orbit queue and the loading queue 

3. 1.4.4 Subroutine FILEO 

This subroutine is called only once from the event 
TERM at the end of the first Monte Carlo cycle. The purpose of the 
subroutine is to print the status information summarized for each 
satellite position, and it processes all items in the set FRS (Appendix 
A). As each item is processed, the necessary program variables are 
reestablished to the instant the item was put into the set. The subrou- 
tine STATUS IS used to reprint the status ,line that corresponds to the 
item in the set. The net result is a time history of activity relative 
to each satellite position As the items in the set are processed, the 
memory storage space used by each item is returned to the SIMSCRIPT 
System. 

3. 1.4.5 Subroutine FILES 

This subroutine is called from the subroutine STATUS 
after the current status of a particular module, satellite, and system 
has been determined. The purpose of the routine is to retain the 
status information for printout at a later time. The subroutine FILES 
IS called with the parameters IS, IM, and 1ST where IS is the pointer 
to the satellite position arrays, IM is the pointer to the module on the 
satellite (if IM is not 0 indicating the item is a satellite), and 1ST is 
the status indicator 1-9 The subroutine adds members to the ranked 
set FRS (Appendix A) as each status line is printed by the subroutine 
STATUS. The set is ranked by satellite position and retains its first-in, 
first-out character with respect to time, therefore, the set is chronolog- 
ical for each satellite position. Sufficient information is carried in the 
set to be able to recreate the print line at a later time 
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3. 1.4.6 


Subroutine GETV 


This subroutine assigns the necessary vehicles to the 
next flight and a flag is set non-zero when vehicles are not available. 

The subroutine GETV is called with the parameter IGO where IGO is 
a flag with two values 0 indicates vehicles are available, and 1 indicates 
vehicles are not available 

The Shuttle fleet availability array is then searched to 
find available vehicles, and those available are noted. However, if none 
are available, the flag IGO is set, and the subroutine returns If a Tug 
is not required, the subroutine also returns. Otherwise, a Tug is located 
in the Tug fleet by the same process In the same manner, if a SEPS is 
not required, the subroutine returns Otherwise a SEPS is found. 

3 14.7 Subroutine ISSUE 

This subroutine is called from the subroutine SHIP when 
the decision has been made to launch a group of payloads There are no 
parameters shown here as all necessary information is available in the 
definition table for the variables lORB, ILOAD, NQ, ISHUT, ITUG, and 
ISEPS {Appendix B) 

The subroutine ISSUE collects statistics on the interval 
of time a class of vehicles (Shuttle, Tug, or SEPS) was unavailable The 
total weight and length of the payload group are computed and printed on 
the first Monte Carlo cycle The subroutine CSPAY is called to gather 
statistics on the individual payloads For all payloads being launched, 
the following events are set up and put into the event queue 

a If the payload is being deployed, the event ARRIV is 

generated, and the occurrence of the launching of the 
payload is recorded in the chronological time history 
by the subroutine STATUS 

b If the pavload is to be retrieved, the events REMOV 

and BACK are generated 

c In the special case of a Sortie flight, the payload will 

be launcaed arrive, and be removed 
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done 


For each vehicle used m the launch, the following is 


1 . 


2 . 


3 

4 


3. 1.4.8 


The event REFVE is generated for when the vehicle 
becomes available again after completion of the flight 
and its associated refurbishment period. 

The specific vehicle in its respective fleet is tagged 
as currently unavailable 

The number of flights for each vehicle involved is 
increased by 1 

If the vehicle is the uppermost stage, the weight of 
the payload group is accumulated for that vehicle 
and the number of times that vehicle is an uppermost 
stage is increased by 1. 

Subroutine LDAT 


The subroutine LDAT (load data) is called once at the 
beginning of the run from the event BEGIN The function of this sub- 
routine is to call the necessary subroutines to load the individual data 
groups from cards into the memory After the subroutine LDAT is 
called, the input error flag IRFLG is set to 0, and the following sub- 
routines are called LDVEH, LDORB, LDMOD, LDSAT, LDSYS, 
LDSCH, LDME, and LDPUR, each with the input error flag IRFLG as a 
parameter. If the error flag is still 0 (meaning no known input errors), 
control IS returned to the event BEGIN Otherwise, the run is stopped 
with the message RUN STOPPED DUE TO DATA ERROR 


3. 1.4. 9 Subroutine LDME 

The subroutine LDME is called once from the sub- 
routine LDAT for the purpose of loading the data for the mission 
equipment upgrade schedules from cards When the subroutine LDME 
(IRFLG) IS called, IRFLG is the input data error flag A non-zero 
value implies a data error was detected 

This subroutine reads a variable number of cards, and 
the extent of the card group is marked by a blank last card. The format 
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of the data card was previously described in detail under input data in 
the Users Guide section of this document The data cards contain the 
system identifier, the system member, the name of the old mission 
equipment, the number of times that the item is repeated on the satel- 
lite, date of the upgrade, and the name of the new mission equipment 
The old equipment module is located in the system on the satellite, and 
the event NEWME is set up for the date of upgrade arid put into the event 
queue Error messages are printed if the system cannot be found, when 
neither mission equipment module is identified as mission equipment, or 
if the mission equipment module is not on the satellite 

3. 1.4. 10 Subroutine LDMOD 

The subroutine LDMOD is called once from the sub- 
routine LDAT for the purpose of loading the data for the modules from 
cards. IRFLG is again the input data error flag, and a non-zero value 
indicates a data error. The subroutine LDMOD reads the number of 
input modules from a card The number is then compared against the 
maximum capacity variable (see Appendix B), MITAB and, if excessive, 
an error message is printed along with setting IRFLG to non-zero If 
the error did occur, the flight would probably fail. The module cards 
are read in (one module per card), and each is promptly printed for 
user reference and verification. 

3.1.4.11 Subroutine LDORB 

The subroutine LDORB is called once from the sub- 
routine LDAT for the purpose of loading the data for the orbits from 
cards As before, IRFLG is the input data error flag and a non-zero 
value indicates a data error. 

This subroutine reads the number of orbits from a card 
The number is compared against the maximum capacity variable NORBS (see 
Appendix B), and, if excessive, an error message is printed along with 
setting the IRFLG flag to non- zero. Such an error would probably cause 
the flight to fail. The orbit data cards are read in (one orbit per card), 
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ar.d each is promptly printed for user reference and verification The 
vehicle name on the orbit data card is checked against the vehicle input 
table, and the name is replaced by a pointer if the vehicle is not found 
in the vehicle input table. 

3. 1 4. 12 Subroutine LDPUR 

The subroutine LDPUR is called once from the subrou- 
tine LDAT for the purpose of cross checking the input data. The user 
is informed of unused modules, satellites, and systems and the appro- 
priate values to use on table sizes. (This reduces memory to a mini- 
mum and may permit the run to be completed ) 

As the subroutine LDSCH processes the satellite launch 
schedules, the variable MARKS (see Appendix B) is set non-zero to indi- 
cate the satellite was used In this routine, each system is scanned for 
required satellites, and the satellite input table and module input table 
have the needed satellites and modules marked by special non-zero entries 
Unused systems are identified in the printout, and, at the end of the scan 
of the systems, a message is printed as to the number of systems this 
model actually uses. Then the satellite and module input tables are 
scanned to list unused satellites and modules and provide the true required 
number of satellites and modules 

3.1,4 13 Subroutine LDSAT 

The subroutine LDSAT is called once from the subrou- 
tine LDAT for the purpose of loading the data for the satellites from 
cards. IRFLG is again the input data error flag, and a non-zero value 
indicates a data error. 

The subroutine LDSAT reads the number of input satel- 
lites from a card, and the number is compared against the maximum 
capacity variable SITAB (see Appendix B). If the number is excessive, 
an error message is printed along with setting the IRFLG to non-zero. 

If the error did occur, the program would probably crash The satel- 
lite data cards are read in groups with two cards for the basic satellite 
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data and one or more cards listing the modules on the satellite The 
entire group is then promptly printed for user reference and verifica- 
tion, and each satellite data group is also printed for user verification 
and reference. In addition, certain input names are replaced by 
pointers to tables for later use by the program. Each satellite is 
assigned to an orbit which must be described in the orbit input table, 
and similarly each module must be in the module input table For 
each module, an item will be filed in the set MDS (Appendix A) for the 
1 *^ satellite. 

3 1.4 14 Subroutine LDSCH 

The subroutine LDSCH is called once from the subrou- 
tine LDAT for the purpose of loading the data for the deterministic 
launch schedules from cards. IRFLG continues to be the input data 
error flag, and a non-zero value indicates a data error was detected 

The subroutine LDSCH reads a variable number of 
schedule cards where the extent of the card group is marked by a last 
blank card The format of the data card is described in detail under input 
data in the Users Guide section of this document The data consists 
of a system name, a member number, and the date of launch After 
the system name is located and the member number identified, that 
information with the date of launch are filed in the set NEWS (see 
Appendix B) for every item to be launched Error messages are 
printed if the system cannot be found or the member number is invalid. 

3.1.4.15 Subroutine LDSYS 

The subi outine LDSYS is called once from the subrou- 
tine LDAT for the purpose of loading the data for the systems from cards. 
IRFLG is still the input data error flag, and a non-zero value indicates a 
data error. 

This subroutine reads the number of input systems from 
a card, and the number is compared against the maximum capacity variable 
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STSTB. If the number is excessive, an error message is printed 
along with setting the IRFLG to non-zero. If the error did occur, the 
program would probably crash. The system data cards are read in 
groups of one or two cards, and each is printed for user reference and 
verification The satellites that are members of the system are found 
in the data cards and located in the satellite input table. The names are 
replaced by pointers to the satellite input table unless the satellite was 
not found, in which case an error message is printed. 

3.1.4,16 Subroutine LDVEH 

The subroutine LDVEH is called once from the subrou- 
tine LDAT for the purpose of loading the data for the vehicles from cards. 
IRFLG continues to be the imprint data error flag, and a non- zero value 
indicates a data error. 

This subroutine reads the number of input vehicles from 
a card, and the number is compared against the maximum capability 
variable NVEH. If the number is excessive, an error message is printed 
along with setting the IRFLG to non-zero. If the error did occur, the 
programs would probably crash fatally. The vehicle data cards are read 
in, one vehicle per card, and each is promptly printed for user reference 
and verification 

3.1.4 17 Subroutine MARKQ 

This subroutine takes all the payloads in the loading queues 
scheduled for delivery to a single orbit and assigns them to the next flight. 
All items in the orbit queue are entered into the flight queue (the array 
ILOAD) up to the maximum capacity of the flight queue IL (see Appendix A) 

3. 1 4. 18 Subroutine MCMOD 

This subroutine consolidates the statistics for modules at 
the end of each Monte Carlo cycle For each module in the module input 
table, the totals are accumulated, and the maximum and minimum counts 
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are found for modules replaced or failed and for warnings of impend- 
ing failure received. 

3. 1 4. 19 Subroutine MCSAT 

This subroutine consolidates the statistics for satellites 
at the end of each Monte Carlo cycle. For each satellite position in orbit, 
the total weight factors are accumulated, and the maximum and minimum 
values are found for each wholly delivered or retrieved satellite, all traffic 
to the satellite, and each module belonging to the satellite In addition, the 
totals, maximums, and minimums are found for the percentage availability 
of each satellite position in orbit. 

3. 1 4. 20 Subroutine MCSYS 

This subroutine consolidates the statistics for satellite 
systems at the end of each Monte Carlo cycle For each satellite system, 
the totals, maximums, and minimums are accumulated for the total weight 
factors in the system and the percentage availability of the system. 

3.1.4.21 Subroutine MCVEH 

This subroutine consolidates the statistics for the vehicle 
fleets at the end of each Monte Carlo cycle For the flights each year, the 
totals, maximums, and minimums are accumulated for the Shuttle, Tug, and 
SEPS vehicles. This same information is also provided for the total flights 
over all years 

3. 1.4 22 Subroutine PASER 

This subroutine accepts a list of payloads destined for the 
same orbit and reorders the list into a sequence of phase angle positioning 
around the orbit The rules for ordering are 

a. Payloads are ordered by increasing phase angle. 

b. The biggest gap in the circle is located, and the necessary 

payloads have their phasing positions decreased by 360 
degrees such that when the list is again in increasing 
sequence, the gap is outside (on the end) of the list 
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c. 


If there is a satellite in the list, the one nearest the 
beginning of the list is moved to the beginning of the list. 

d. The logic can reorder the list in the reverse direction 

if the satellite is at the "wrong end " 

The parameters are accessible in the definition table in the 
variables NQ and ILOAD (Appendix B). The ILOAD array points to the 
individual payloads in the loading queue and is therefore rearranged in 
the desired sequence. 

3 1.4.23 Subroutine PAYLQ 

The function of this subroutine is to put a payload into its 
orbit queue and the loading queue The subroutine PAYLQ is called with 
the parameters IS and IM where IS is the pointer to the specific satellite 
in an orbit position and IM is the pointer to the element MODSY (Appendix 
A) identifying the specific module. If it is 0, the item is a satellite. 

The elements ITORB and PAYLD (Appendix A) are created, 
values for all members of each element are defined as necessary, and the 
elements are filed into the orbit queue and loading queue 

3.1 4.24 Subroutine PROP 

This subroutine has the responsibility for computing the 
propellant reqmred to deliver a group of payloads to their respective 
orbital destinations on a specified upper stage The subroutine PROP is 
called with the parameter IGO where IGO is a vehicle availability flag. If 
IGO is not 0, then the flight cannot be flown at this time. 

The other parameters are accessible in the definition 
table and are the portion of the loading queue as defined by variables NQ 
and ILOAD (Appendix B) and vehicle data. The subroutine returns the 
flight configuration in terms of sequence and time of arrival after launch 

j 

or a no-go status which indicates the payload group cannot be delivered 
due to propellant restrictions or that the group is of excessive volume. 
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The functions performed within this subroutine can be 
separated into options for Sortie, Shuttle only, SEPS, and standard upper 
stage delivery 

The Sortie option checks the loading queue to determine 
how many Sorties are waiting If no Sorties are in the queue, the routine 
looks for other options If only one Sortie exists, all other payloads are 
Ignored, and the next available launch is assigned to carry a single Sortie 
payload If more than one Sortie is in the queue, the flight is rejected 
No volume check is performed as the delivery is a single payload. 

The Shuttle-only option determines the weight of payloads 
to be delivered and to be retrieved. If either value exceeds the variable 
WCONS as input on the appropriate Shuttle card, the flight is declared no 
go A volume check is also performed. 

The SEPS option is used for orbits that have SEPS specified 
on the orbit data card The flight is first tried on the upper stage without 
the SEPS, and, if the upper stage alone can make the flight to orbit, then 
the SEPS will be used only for phasing The payload queue could continue 
to grow due to the waiting feature of the remainder of the program In that 
case, if an upper stage vehicle could not perform the flight, the flight would 
be made using the upper stage and the SEPS 

The standard upper stage delivery option comprises the 
major portion of the code in the routine This option includes the follow- 
ing features 

a. The number of service units is determined from the 

number of modules on the flight and the permissible 
number of modules in a service unit 

b The volumetric check is made 

c The data for the orbit is obtained from the definition area. 

d The weights for deployment, service, and retrieval are 

determined from the loading queue 

e. The vehicle data is passed stage by stage to the FORTRAN 

code via the FORTRAN linkage subroutine LINKT 

f The subroutine PASER is called to determine the delivery 

sequence of the payloads in the loading queue 
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g. The ordered loading queue of payloads is changed to a 

senes of orbital legs, each carrying a weight and 
requiring a 4V from the vehicle 

h The FORTRAN subroutine PRFORM is called to deter- 

mine the amount of propellant remaining at the end of 
the flight composed of orbital legs 

1 . If the amount of propellant remaining is positive, the 

data pertinent to the flight are saved in the loading queue 
and the orbit queue. 


3.1 4.25 Subroutine QDMP 

The function of this subroutine is to remove duplicate 

t 

payloads from the loading queue and to inhibit modules from entering 
the queue when their satellite is in the queue It is called whenever a 
new payload is about to be put into the loading queue The subroutine 
QDMP is called with the parameters IS, IM, and ILL where IS is the 
pointer to the specific satellite in an orbit position, IM is the pointer to 
the new element MODSY (Appendix A) identifying the specific module or 
if 0, the item is a new satellite, and ILL is a flag with two values =0 
implies new payload can be put into the loading queue and ^0 implies new 
payload cannot be put into the loading queue 

The following rules apply to comparing the new payload 
against the entire portion of the loading queue pertaining to the orbit of 
the new payload. 


a. If the new payload is a Sortie mission,the routine dis- 

continues processing and returns 

b If the new payload is to be retrieved, and there are 

several satellites still in the orbit position, the routine 
returns 

c If the orbit queue is empty, the routine returns 

d. If the new payload is identical to a payload in the queue, 
the previous payload is removed from the queue by the 
subroutine DROPQ. 

e. If the new payload is a satellite, and a module is des- 
tined for delivery to the same orbit position as the satel- 
lite, the module is removed from the loading queue by 
the subroutine DROPQ, 
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f. If the new payload is a module, and a satellite is des- 

tined for delivery to the same orbit position as the 
module, the flag ILL is set to 1, and the routine returns 

3. 1.4 26 Subroutine QUAD 

This subroutine is used to force angles into the region 
from 0-360 degrees The subroutine QUAD is called with the parameter 
A where A is the input angle to be put into the region 0-360 degrees. If 
A is negative, A is increased by 360 degrees until A is positive. If A is 
greater than 360 degrees, then A is decreased by 360 degrees until A is 
less than 360 degrees 

3.1 4.27 Subroutine REDUN 

This subroutine will determine the redundant nature of a 
given module on a specific satellite. The subroutine REDUN is called 
with the parameters IS and IM where IS is an index to the satellite at an 
orbital position and IM is a pointer to the module on a satellite 

The variable DELTA is accessible via the definition sec- 
tion (Appendix B). The subroutine will locate the module, determine if it 
is in a redundant group, and set DELTA as follows 


a 

0 

Failure of this module will render the satellite 
inoperative. 

b. 

3000 

Failure in a redundant group with satellite still 
operative 

c. 

-3000 

Last permissible failure in a redundant group, 
one more failure and DELTA will be 0 


3. 1 4 28 Subroutine SAVER 

This subroutine is used to create satellite replacements 
automatically It is called when the satellite becomes operational because 
an entire satellite is put in orbit, and it is called when an NRU fails The 
subroutine SAVER is called with the parameters T2 and IS where T2 is 
the moment of termination of the satellite and IS is the index to the satel- 
lite in orbit The subroutine generates the events NWSAT and RETRI as 
necessary for the policy variable POLDN (Appendix B). 
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3.1,4.29 Subroutine SHIP 

This subroutine receives payloads to be launched from 
events that have just occurred The subroutine controls the loading 
algorithm and makes the decision of when to launch The subroutine 
SHIP IS called with the parameters IS and IM where IS is the index to 
the satellite in orbit table and IM is the address pointer to the module 
on the satellite (if not 0). 

The payload is entered into the loading queue via calls 
to subroutines QDMP and PAYLQ. The entire queue is scheduled for 
launch (subroutine MARKQ), and the flight is attempted (subroutine 
PROP). If there is usable propellant remaining at the end of the flight, 
the subroutine returns Otherwise, the record of the previous good 
launch is checked, and, if present, that set of payloads is launched 
(subroutine ISSUE) If the record is not present, the subroutine will 
construct a series of payload groups beginning with the first payload 
alone, save the record (if good), add the next payload from the first-in 
first-out queue to the group and iterate until the payload group exceeds 
the launch capability The preceding group of payloads can then be 
launched. The subroutine includes logic to upgrade the launch vehicle 
to expendable if a single payload requires the increased performance 
The loading sequence is tried again, and usually the entire loading 
queue can be flown The subroutine would then return leaving the 
record of a good launch on an expended vehicle. 

The subroutine can also be entered with IS equals 0 
for the occurrence of a mandatory launch forced by a payload in the 
loading queue or with IS less than 0 for the occurrence of a vehicle 
becoming available and the sensing of an impending launch being delayed 
by no vehicle available for the launch If there is space available on a 
mandatory launch, mo'dules destined for redundant systems can be 
carried. If a payload is too heavy to be carried on an expendable 
vehicle, the subroutine deletes the payload from the queue and enters 
a message in the time history. 
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3. 1 4. 30 


Subroutine STATUS 


This subroutine is called when events occur for modules 
or satellites and performs three functions 

a The status (active, inactive, or permanently disabled) 

IS determined for the module, its satellite, and its 
system 

b The statistics are gathered for availability and outage 

intervals for the satellites and the system 

c The routine prints the lines in the two chronological 

time histones generated on the first Monte Carlo cycle. 

The subroutine STATUS (IS, IM, 1ST) is called with the 
parameters IS, IM, and 1ST where IS is the index to the satellite in orbit 
table, IM is the pointer to the module on the satellite (if it is not 0, and 
1ST varies from 1-10, depending on which event is occurring 

3.1.4 31 Subroutine TERMQ 

This subroutine prints the statistical summaries at the 
end of the run The summaries generated include the following reports 

a Flight summary of Shuttles, upper stages, and SEPS for 

each year followed by a totals line and the count of upper 
stages expended in the run (if not 0) 

b Weight summary of average launch weight delivered to 

each orbit by Shuttles, upper stages, and SEPS 

c System summary of statistics for module replacement 

and associated load factors for each module on its individ- 
ual satellite in orbit (The satellite in orbit is displayed by 
replacement of whole satellites with associated load 
factors and percentage availability and outage intervals.) 

d Module summary showing the failures, warnings, and 

replacements on all satellites for all modules 

3. 1.4 32 Subroutine WEIBUL 

This subroutine is called whenever a module is switched 
on or to an active state The purpose of the subroutine is to predict the 
random occurrence of a failure and/or warning of the module at some time 
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in the future. The subroutine WEIBUL is called with the parameters 
AW, BW, TW, AF, BF, and TF where AW is the Weibul parameters 
for warning, BW is the Weibul parameter (3 for warning, TW is the 
predicted time interval to the occurrence of the warning, AF is the 
Weibul parameter a for failure, BF is the Weibul parameter P for 
failure, and TF is the predicted time interval to the occurrence of the 
failure. 

The following alternatives are covered by routine 

WEIBUL 


a. If AW IS 0 for the module, TW is then 0, implying no 
warning can ever occur for this module. 

b. If AF IS 0 for the module, TF is then 0, implying no 
failures can ever occur for this module. 

c If AW IS 0 and AF is not 0, TF is defined by 


jl/BF 

where R is the next sample from the random number 
n 

generator. 

d. If both AW and AF are not 0, then TW is defined by 

e 

and TF is defined by 

TF = - AW • I log 

V ^ 

This form assures TF > I 
3. 2 ELEMENTS OF FORTRAN IV 

3 2 1 Linkage Subroutines List 

The following linkage subroutines exist for the sole 
purpose of passing data between SIMSCRIPT subroutines and FORTRAN 
subroutines The FORTRAN subroutines then communicate the data via 


TW = - AW 


log 


R 


1/BW 




R /TW\ 

n e ( AF ) 


BF\ 1/BF 




TF = - AF 


log R 


n 
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labeled common This is done to expedite the integration of the sub- 
routines written in the two languages. 


3.2. 1, 1 Subroutine CON 

This subroutine is used to convert the NRU or redundant 
entries for each module on each satellite The subroutine CON is called 
with the following parameters 


a. 


b. 


3.2. 1, 2 


parameters 


a 

b 


c. 


1 IS the four -character entry after the module on the data 
card. 

K is the returned value of the converted entry as follows 
1, 0 is blank or O(SRU). 

2 1-15 IS 1-15 (redundant SRU) 

3. 100 IS anything else (NRU) 

Subroutine CONEC 

The subroutine CONEC is called with the following 


NS is the number of stages on the vehicle. 

NVEH IS not used 

ISEPS IS the SEPS flag, and non- zero means the SEPS 
IS to be used 


3.2. 1.3 

parameters 

a 

b 

c 

d. 

e. 

f 

g- 

h 


Subroutine LDSEP 

The subroutine LDSEP is called with the following 
A IS the structural weight 

B is the solar electric propulsion efficiency 
C is the solar cell power for thrust 
D IS the I 

sp 

H IS the performance reserve factor 
I is the vehicle expend flag 
F is the total thrust time in days 
G is not used. 
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3 . 2 . 1.4 


parameters 

a 

b. 

c 

. d. 

e. 

f. 


h. 

3 . 2 , 1.5 

parameters 

a. 

b 

c. 

d. 


e. 


3 . 2 . 1.6 


parameters 

a. 


b. 


Subroutine LINKT 

The subroutine LINKT is called with the following 

I is the number of the stage. 

A IS the I of the stage. 

sp ® 

B IS the inert weight of the stage 
C IS not used 

D IS the maximum propellant in the stage 

E IS the expend flag, and a non-zero value means expend, 

F IS the solid flag, and a non- zero value means a solid 
stage. 

G IS the gross weight of the stage including payload. 
Subroutine SEPSV 

The subroutine SEPSV is called with the following 


N is the number of service legs 
PER is not used 
VS is not used 

DT IS the array of differences in phase angles for each 
service position 

PAY IS the corresponding array of payload weights to be 
transported across each phase angle. 

Subroutine TFHAS 

The subroutine TPHAS is called with the following 


A is the array of the time of flight of the SEPS during a 
sequence of phasing maneuvers, 

N IS the number of maneuvers 
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3.2. 1.7 


Subroutine TWOBR 


The subroutine TWOBR is called with the following 

parameters 

a. DV IS the total AY for the transfer 

b. DVl IS the AY for the first burn of two. 

3.2 2 Vehicle Performance Subroutines List 

The subroutines in the following paragraphs are coded in 
fortran and provide various vehicle performance computations. 

3. 2. 2. 1 Subroutine PRFORM 

This subroutine determines which performance subrou- 
tine is to be called The subroutine PRFORM is called with the follow- 
ing parameters 

a. DVLEG is the name of the array containing the AY 

for each leg in the order of deployment 

b PLEG IS the name of the array containing the pay- 

load weight for each leg 

c. NLEG IS the integer number of legs to be simulated 

d. WPER IS the minimum percentage value of the residual 
propellant or the excess capability in gross weight 

e NEXIT IS the type of mission exit (1-9) from the subrou- 

tine SEPX, 1 e , whether the mission is possible or not. 

f. ERFLG = 0 (do not erase the previous maneuver) 

= 1 (erase the previous maneuver) 

g NT IS the number of Tugs used in the SEPS mode. 

The other data required to compute performance are 
passed via the linking subioutines 

3 2.2 2 Subroutines SEPX, SEPIM, TUGCP, CRYOl, INTORB, 

SEPDV, PLUPD, and FAZS 

This IS an integrated group of subroutines designed to 
determine the performance capability of a specified Space Tug/Solar 
Electric Propulsion Stage (SEPS) combination for any number of 


3-31 



deployment/ servicing/ retrieval missions to synchronous equatorial orbit 

In normal usage, a call is made to the executive sub- 
routine SEPX contaimng information on the mission to be flown (e. g. , 
weight to be deployed, weight to be retrieved, and servicing maneuvers 
to be performed in synchronous orbit). The program determines the 
optimal (minimum SEPS fuel) intermediate orbit at which changeover 
should occur based upon the characteristics of the Tug and SEPS vehicles 
which are stored in a common area. Program outputs include intermedi- 
ate orbit altitude and inclination, SEPS ascent and descent times, and 
SEPS fuel remaining at the end of the mission 

The subroutine SEPX is called with the following 
parameters . 

a. MPLA IS the weight of payload to be deployed (lb) 

b. MPLB IS the weight of payload to be retrieved (lb) 

c. ERFLG = 0 (do not erase the previous maneuver). 

= 1 (erase the previous maneuver). 

d. NEXIT IS the type of mission exit (1-9) from the 

programs, i e., whether the mission is possible 

or not. 

The following variables are passed via labeled common 

a, SEPS data 

1. MS is the mass of the SEPS (lb), 

2. P IS the solar cell power (watts), 

3 E IS the solar electric propulsion efficiency 

4 SISP IS the SEPS I (sec). 

sp 

5 TSEP IS the thrusting time available on a fully 
fueled SEPS (days). 

6 MPT IS the mass of propellant on board (lb). 

7 TLEFT IS the corresponding thrusting time (days) 

8. RSEP IS the performance reserve factor for the SEPS 

2 

9 SG IS the gravity constant (ft/ sec ). 
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b Tug data 

i TWS IS the Tug structural weight (lb). 

2, TWPA is the allowable Tug propellant weight (lb) 

3 TISP IS the Tug effective I (sec). 

sp 2 

4. TG IS the gravity constant (ft/ sec ). 

5. TWGA is the gross weight allowable (lb). 

6 TR IS the performance reserve factor for the Tug. 

c Returned data 

1 NTUGS IS the number of Tug flights required to 

perform the mission and return the expended 
SEPS, if required. 

2. TLEFT is the SEPS life remaining after accom- 

plishing the mission (days). 

3 MPT IS the SEPS fuel remaining after accom- 

plishing the mission (lb). 

4. HGO IS the optimal changeover orbit altitude (nmi) 

5. ICOS IS the optimal changeover orbit inclination 
(deg). 

6 TU IS the time required by the SEPS for ascent 

maneuvers (days). 

7. TD IS the time required by the SEPS for descent 

maneuvers (days). 

The simulation of the Space Tug/ SEPS operation is per- 
formed using the following set of subroutines 

3.2. 2.2. 1 SEPX 

1 

This IS the executive subroutine In it, the decisions are 
made as to when a new SEPS must be launched or retrieved and whether the 
given deploy and retrieve payloads commands can be handled in a single 
Tug/SEPS encounter or whether additional Tug flights are required to 
support the mission. This logic has been kept separate from the SEPS 
performance equations to facilitate logic changes incorporating mission 
modes other than the ground-based mode which is presently baselined 
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3. 2. 2. 2. 2 


SEPIM 


In this subroutine, the performance of the Tug/SEPS 
combination is computed by calls to more detailed performance sub- 
routines. The delivery, servicing, and retrieval of payloads are 
accomplished, and the fuel and time remaining on the SEPS are decre- 
mented accordingly. 

3.2. 2. 2. 3 TUGCP 

This subroutine calls the appropriate Space Tug configu- 
ration to determine the Tug capability. Presently only a single-stage 
cryogenic Tug performance model (CRYOl) is available 

3.2. 2. 2.4 CYROl 

In this routine, the AV capability of a single-stage 
cryogenic Space Tug carrying the required deploy and retrieve payloads 
is computed. The Tug is initially either filled with propellant or filled 
to the gross weight limit of the Shuttle. Impulsive zlV's are assumed 
with a specified performance reserve to allow for finite burn effects and 
propellant margin 

3.2. 2.2.5 INTORB 

From the AV which can be supplied by the TUG, this 
subroutine computes the optimal (minimum SEPS fuel required) change- 
over orbit altitude and inclination. This is done by a table look-up 
procedure, since the optimization study for a synchronous equatorial 
mission orbit has been previously accomplished in a manner that is 
dependent only upon the which can be supplied by the Tug 

3.2. 2. 2. 6 SEPDV 

Given the optimal changeover orbit calculated by sub- 
routine INTORB, SEPDV determines the 4V (and corresponding mass 
ratio) which must be expended by the SEPS. Edelbaum's simplified 
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equations for low-thrust vehicles are used in calculating the 4V 
required Again, a performance reserve factor is provided 

3. 2 2. 2, 7 PLUPD 

With the mass ratio from subroutine SEPDV, this sub- 
routine decrements both the propellant on board and the SEPS remaining 
lifetime for each payload carried up or dovn by the SEPS 

3.2. 2,2.8 FAZS 


The subroutine performs the on-orbit servicing man- 
euvers using the SEPS and decrements the fuel and lifetime of the SEPS 
accordingly 

3. 2. 2. 3 Subroutine SSHOT 


This subroutine computes the propellant necessary to 
deploy payloads by the "slingshot” method. The subroutine can handle 
up to 3 liquid (variable burn) stages and 10 legs The "slingshot" method 
refers to a type of deployment in which the lower stages boost the upper 
stage into the service orbit The stages may be recoverable or not and 
only the upper stage does the servicing A leg is the service loop, that 
part of the trajectory between two service /deploy events 

The subroutine SSHOT is called with the following parame- 


ters 


a. DVLEG is the name of the array containing the AV for 
each leg in the order of deployment 

b. PLEGis the name of the array containing the payload 
weights for each leg. 


Edelbaum, T N , "Propulsion Requirements for Controllable 
Satellites, " ARS Journal, pp. 1079 - 1089 (August 1961), 
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c. NLEG IS the integer number of legs to be simulated. 

The following variables are passed via labeled common 


a. 


b 


c. 


d. 

e 

f. 


WS IS the name of the array for the structure weights 
for each stage (lb). 

WPA IS the name of the array for the allowable pro- 
pellant weight for each stage (lb). 


EISP IS the name of the array for the effective I 
each stage (sec). 


sp 


for 


NSTG is the integer number of stages to be processed 

FEAS(l) is the ratio of the weight of the propellant nec- 
essary to the weight of the propellant available 

FEAS(2) is the ratio of the gross weight necessary to the 
gross weight allowable 


Given the propellant allowable, the structure weights, and 

the I for each stage and the required for the payloads for each leg, 
sp 

the subroutine computes the amount of fuel necessary to perform the mission. 
The weight of the propellant is then divided by the weight allowable and the 
ratio is returned to the user as an index of feasibility 


3. 2. 2.4 Subroutine SSLQD 


This subroutine computes the propellant necessary to 
deploy payloads with a single liquid stage. There may be multiple deliver- 
ies (legs) required 

The subroutine SSLQD is called with the following parameters 

a. DVLEG is the name of the array containing the for each 
leg in the order of deployment 

b. PLEG IS the name of the array containing the payload weight 
for each leg. 

c. NLEG IS the integer number of legs to be simulated. 

The following variables are passed via labeled common 

a WS IS the name of the array for the structure weight for 

the stage (lb). 

b. WPS IS the name of the array for the allowable propellant 

weight for the stage (lb) 
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c. 


d. 


e 

f 


g- 


EISP IS the name of the array for the effective for 
the stage (lb), 

2 

G IS the gravity constant (ft/sec ). 

WGA IS the allowable gross weight (lb). 

FEAS(l) IS the ratio of the weight of the propellant 
necessary to the weight of the propellant available. 

FEAS(2) IS the ratio of the gross weight necessary to 
the gross weight allowable. 


Given the weight allowable, the structure weights, the 

I of the stages and the required for each payload, the subroutine 
s p 

computes the required propellant and then forms the ratio of the total 
weight to the allowable weight. This ratio is returned as an index of 
feasibility 


3. 2. 2. 5 Subroutine TRNKC 


This subroutine computes the propellant necessary for 
the liquid burn stage with the restriction that the solid stage(s) is totally 
consumed. The subroutine will handle either one or two kicks to boost 
a single payload into its orbit. 

The subroutine TRNKC is called with the following 

parameters 

a. DVLEG(l) is the name of the array for the require- 
ment for a low-altitude burn 

b. DVL/EG(2) IS the name of the array for the AV require- 
ment for a high- altitude burn 

c. PLEG(l) is the name of the array containing the weight 
of the payload to be deployed 

d NLEG IS set equal to 2. 

The following variables are passed via labeled common 

2 

a G IS the gravity constant (ft/ sec ) 

b. WGA IS the allowable gross weight (lb) 

c . REUSE IS the name of the array containing the flags denot- 

ing whether the stage is reusable or expendable 0 = 
expendable and non-zero = reusable 
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d. 


e. 


f. 


g- 


h. 


1 . 


FEAS{1) IS the ratio of the weight of the propellant 
necessary to the weight of the propellant available. 

FEAS(2) is the ratio of the gross weight necessary 
to the gross weight allowable 

WS IS the name of the array for the structure weights 
for each stage (lb). 

WPAis the name of the array for the allowable pro- 
pellant weight for each stage (lb). 


EISP is the name of the array for the effective 
for each stage (sec). 


I 

sp 


NSTG is the integer number of stages to be processed 


Given the allowable propellant weight, the structural 
weights, and the effective for each of the stages, the subroutine com- 
putes the solid stages (s) capabilities. Then, if needed, it determines the 
remaining requirement for the liquid first stage It is assumed that the 
solid stage(s) is totally expended, but if it is not expended, the residuals 
are burned off by yaw steering. 
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APPENDIX A DESCRIPTION OF QUEUES 


A queue is defined as a waiting line. In the LOVES Computer 
Program, there are eight queues in operation 


EVENT 

- 

Events which will occur in the future 

FRS 

- 

Summary of activity for each satellite 

LOAD 

- 

All payloads awaiting delivery 

MDS 

- 

Modules initially comprising each satellite 

MES 

- 

Input mission equipment changes 

MOD 

- 

Modules currently comprising each satellite 

NEWS 

- 

Input satellite launch schedule 

ORB 

- 

Payloads waiting to be delivered to 
individual orbits 


Each queue contains elements consisting of groups of compu~ 
ter words. For example, all events require four words of memory. The 
words within a group can be subdivided so that the data can be packed. LOVES 
uses 1/4 word minimum for some integer variables, 1/3 word for some larger 
integer variables, 1/2 word for integers that could be addresses, and full 
words for floating point variables 

In the following pages of this appendix, each queue is des- 
cribed in detail. 

A 1 THE EVENT QUEUE 

The EVENT queue is automatically handled by the SIMSCRIPT 
system as to which is the next event to occur The programmer sets up the 
events, and, when they occur, he destroys each event. The events used in 
the LOVES Computer Program were described m detail in the Programmers 
Manual section of this document and are listed below 


External 

Internal 

BEGIN 

ARRIV 

LAUNC 

REF MO 

REMOV 

START 


BACK 

NEWME 

REFSA 

RETRI 

TERM 


FAIL 

NWSAT 

REFVE 

SATDN 

WARN 

PRECEDING PAGE BLANK NOT FILMED 
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Each event is four words in size The first two words of 
each event are reserved for SIMSCRIPT bookkeeping. The third word 
has two definitions, depending on the event 


TIMEl 


or 


PS AT 


PMOD 


a TIMEl - IS a time-data word. 

b PSAT - IS a 1/ 2-word pointer to a satellite position 

in the orbit. 

c. PMOD - is a 1/2-word address pointing to a module 

on the satellite. 

The fourth word has three definitions, depending on the 
event Each uses the full word 


a. 

b. 

c. 


TIME2 
VNAME 
TIME A 


is the second time-date word. 

IS the name of a vehicle. 

is the time of arrival of a satellite in orbit. 

It is used to inform a module failure event 
that the original satellite is gone, and, there- 
fore, the event really cannot occur. 


A. 2 THE QUEUE FRS 

This queue retains a record of everything that occurs with 
respect to modules and satellites No vehicle events are in the queue. The 
queue is built during the first Monte Carlo cycle and destroyed at the end of 
the cycle Therefore, somewhere near the end of the first Monte Carlo 
cycle, the program attains its maximum size The queue is ranked by 
satellite position in orbit, and, due to SIMSCRIPT filing equal elements 
at the end of the queue, the queue is kept m the correct time sequence. 
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A simple scan of the queue produces the chronological time history of each 
satellite position. If TRIG2 is non-zero, the queue is not built, the report 
will not be printed, and the memory requirement for the program is reduced 
The structure of an item in the queue is 


SFRS 

PFRS 

TIMEF 

SATNO ST 

SATSY NFS 

MODNO 

NOSTA 


The item is four words in size and called FR The definition 
of the names in the item are 


a 

SFRS 

is a 1/2-word address pointing to the next item 
in the queue 

b. 

PFRS 

IS a 1/2-word address pointing to the previous 
item in the queue 

c. 

TIMEF 

is the time at which an event occurred. 

d. 

SATNO 

is a l/4-word pointer to the satellite orbit 
position involved in the event 

e 

ST 

IS a 1/4- word for the status of the satellite 
after the event 

f. 

SATSY 

IS a 1/4-word for the status of the system 
after the event. 

g 

NPS 

is a l/4-word for the number of satellites at 
the orbit position after the event 

h 

MODNO - 

IS a l/2-word address pointing to the module 
on the satellite, if it is non- zero 

1. 

NOSTA 

is a 1/ 2-word for the event identifier. 


THE QUEUE 

LOAD 


This queue contains all payloads available for deployment 
and/or retrieval at a given instant of time. The queue is ranked in ascending 
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order based on the time on the simulation clock at which the item is 
entered into the queue The structure of an item in the queue is 


SLOAD 

PLOAD 

IMOD 

IS AT 

IRT 


ANGLE 


PAYWT 

PAYLN 

GOTIM 


LQTIM 

CITEM 


The item is eight words in size and called PAYED. The 
definition of the names in the item are* 


a. 

SLOAD 

IS a 1/2-word address pointing to the item in 
the queue 

b. 

PLOAD 

is a 1/2- word address pointing to the previous 
item in the queue 

c 

IMOD 

IS a 1/2-word address pointing to the module 
(if non- zero). 

d. 

ISAT 

is a 1 /4-word index to a satellite in the orbit 
table. 

e. 

IRT 

is a 1 /4-word flag If it is 0, the payload is for 
deployment, if it is non- zero, the payload is for 
retrieval. 

f. 

ANGLE - 

IS the angular position in the orbit of a satellite. 

g* 

PAYWT - 

IS the weight of the payload 

h. 

PAYLN 

is the length of the payload. 

1 . 

GOTIM 

is the time interval between launch and arrival 
in the orbit of the payload. 
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J LQTIM - IS the time the payload enters the loading 

queue 

k CITEM - IS a 1/ 2-word address pointing to the corre- 

sponding item in the queue ORB. 

A 4 THE QUEUE MDS 

This queue contains the list o£ modules comprised in the 
original satellite Therefore, there is one of these queues attached to each 
satellite. Each queue is first~in first-out, so that the printouts match the 
input data. The structure of an item in the queue is 


SMDS 

1 

NOMOD 1 


NRU 




The item is four words in size and called MDSAT The 
definition of the names in the item are 


a. 

SMDS 

IS the l/2-word address pointing to the next 
item in the queue 

b. 

NOMOD - 

IS the 1/2-word pointer to the module 
module table. 

in the 

c 

NRU 

is a 1/4-word flag for the NRU, SRU, 
redundant module. 

and 


A. 5 THE QUEUE MES 

This queue retains the schedule of mission equipment 
changes or upgrades as supplied by the input data deck The queue is 
scanned at the beginning of each Monte Cailo cycle, and, for each item in 
the queue, an event NEWME is put into the event queue The queue is last-in 
first-out to minimize the core requirement The structure of an item in the 
queue is 
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SMES 


MEET 

PSAT 

PMOD 



The item is four words in size and called MESET. The defini- 
tion of the names in the item are 


a. 

SMES 

- IS a 1/2-word address pointing to the next item 

in the queue 

b. 

MEET 

- IS the date at which the mission equipment 

change is to occur 

c. 

PSAT 

- IS a 1/2-word pointer to the satellite position 

in orbit. 

d. 

PMOE 

IS a 1/ 2-word address of the module on a 
satellite to be upgraded. 


A. 6 THE QUEUE MOD 

This queue contains the list of modules comprised in the 
current version of the satellite located at its orbital position Therefore, 
there is one of these queues attached to each satellite in orbit Each queue 
IS first-in first-out. The structure of an item in the queue is 


SMOE 

NOMOE 

EFAIL 

NUM 

NRU 

MAXNU MINNU 

MSTAT 

SUMNU 

EOAEF 

SUMLF 

MAXLF 

MINLF 

EEO 


EWARN 
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The item is eight words in size and called MODSY. The 
definition of the names in the item are 


a. 

SMOD 


is a 1/2-word address pointing to the next 
item in the queue. 

b. 

NO MOD 

- 

is a l/2-word pointer to the module in the 
module table 

c 

EFAIL 

- 

IS a l/2-word address pointing to a module 
failure event, if it is non-zero. 

d. 

NUM 


is a 1/4-word for the number of times the 
module alone was launched during a Monte 
Carlo cycle 

e. 

NRU 

- 

IS a 1 /4-word flag for the NRU, SRU, and 
redundant module 

f 

MAXNU 

- 

IS a 1/4-word for the maximum value of NUM 
over all cycles 

g- 

MINNU 

- 

is a l/4-word for the minimum value of NUM 
over all cycles. 

h. 

MSTAT 

- 

IS a 1/4-word for the active/ inactive status 
flag of the module 

1 

SUMNU 

- 

IS a 1/4-word for the sum of NUM over all 
Monte Carlo cycles 

J 

LOADF 

■ 

IS a 1/3-word for the sum of the load factors 
changed to this module over one Monte Carlo 
cycle 

k. 

SUMLF 

- 

is a l/3-word for the sum of LOADF over all 

1. 

MAXLF 

- 

cycles. 

is a 1/3-word for the maximum value of LOADF 
over all cycles 

m. 

MINLF 

- 

IS a 1/3-word for the minimum value of LOADF 
over all cycles 

n. 

EDO 

- 

IS a 1/3 -word flag for a warned or failed module 
in a group of redundant modules. 

o 

EWARN 

- 

IS a 1/ 2-word address pointing to a module 
warning event, if it is non- zero 


A 7 THE QUEUE NEWS 

This queue retains the launch schedule of satellites as supplied 
by the input data deck The queue is scanned at the beginning of each Monte 
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Carlo cycle, and, for each item in the queue, an event NWSAT is put into 
the event queue. This queue is LIFO (last-in first-out) to minimize the 
core requirement The structure of an item in the queue is 


SNEWS 


SCHSY 


SCHDT 


The item is two words in size and called NEW. The defini- 
tion of the names in the item are 


a. 

SNEWS 

is a 1/2-word address pointing to the next 
item in the queue 

b. 

SCHSY 

IS a 1/ 2-word pointer to the satellite in the 
orbit table identifying which satellite is to be 
launched. 

c. 

SCHDT 

IS the scheduled launch date of a satellite 


Because this queue is LIFO, satellites become available for 
launch in reverse order of the input data. 

A. 8 THE QUEUE ORB 

This queue retains the list of payloads going to each specific 
orbit. It is therefore many queues, each queue belonging to a separate orbit. 
Each queue is ranked in ascending order, based on the time on the simulation 
clock when the item is entered into the queue The structure of an item m the 
queue is 
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The item is four words in size and called ITORB. The 
definition of the names in the item are 

a. SORB - IS a 1/ 2-word address pointing to the next 

item in the queue 

b PITEM - IS a 1/2-word address pointing to the payload 

in the loading queue 

c PORB - IS a l/2-word address pointing to the previous 

item in the queue 

d. TORB - IS the time on the simulation clock when the 

item is entered into the queue 

Each item in this queue is matched by a corresponding item 
in the queue LOAD 
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APPENDIX B DEFINITION OF VARIABLES 


This appendix provides a description of all the permanent 
variables entered in the Definition Section preceding the SIMSCRIPT Program 
Code, These variables are accessible to all SIMSCRIPT subroutines and 
events. The list is important, as it identifies the entries in the initializa- 
tion section of the data deck. Items with numbers 60, 80, 85, 100, 120, 130, 
140, 150, 180, 200, 230, and 270 are especially of interest, since they are 
used to dimension the vector-type variables immediately following them 
The relationship can be seen by referring to the beginning of the sample 
printout in Appendix C. 
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GLOBAL VARLA.BLES AND CONSTANTS 


ARRAY NO 

NAME 

DESCRIPTION 

1 

UP 

A six-letter constant used to print the 
status of an operating elenaent 

2 

DOWN 

A six-letter constant used to print the 
status of a temporarily inoperative element 

3 

OUT 

A six-letter constant used to print the 
status of a permanently disabled element 

4 

SHUT 

A six-letter constant used to print the 
name of the Shuttle 

5 

TUG 

A six-letter constant used to print the 
name of the upper stage 

6 

SEPS 

A six-letter constant used to print the 
name of the SEPS vehicle 

7 

BLANK 

A six -letter constant containing blanks 

8 

G 

Gravity constant 

9 

TIMEB 

Time to begin collection of statistics in 
years 

10 

TIMES 

Time to terminate collection of statistics 
in years 

11 

TIMEC 

Monte Carlo random number control vari- 
able If = 0, program uses random num- 
bers If 0<TIMEC<1 , the program uses 
TIMEC as the only random number sample 

12 

PDOWN 

Global policy indicator for retrieving 
modules 



=0, all modules retrieved 
^0, all modules are collected at the end 
of the phasing maneuver, but not 
returned to earth. 

13 

NINSU 

Maximum number of modules carried by a 
service unit 

14 

WTSU 

Weight of empty service unit 

15 

LENSU 

Length of service unit 
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ARRAY NO 


NAME 


DESCRIPTION 


16 NMD Number of modules assigned to current 

flight 

17 SU Number of service units assigned to cur- 

rent flight 

18 WAITl The time interval in days after the termin- 

ation of a satellite, shall the replacement 
satellite be put in loading queue (+ or -) 

19 WAIT2 The time interval in days after the repla- 

cement satellite is scheduled, shall the 
retrieval of the satellite be scheduled into 
the loading queue (+ or -) 

20 WSATU The maximum wait for a satellite launch 

after a satellite enters the loading queue 
if the satellite to be replaced is operational 

21 WSATN The maximum wait for a satellite launch 

after a satellite enters the loading queue 
if the satellite to be replaced is inoperative 

22 WMODU The maximum wait for a module launch 

after a module enters the loading queue if 
the module to be replaced is operational 

23 WMODN The maximum wait for a module launch 

after a module enters the loading queue if 
the module to be replaced is inoperative 

24 TRIG The current count of the number of Monte 

Carlo cycles performed 

25 TRIG2 A flag.if zero, collect and print chronolog- 

ical history for each satellite 

26 TRIGS Number of Monte Carlo cycles to be 

simulated 

27 EXVEH Expend vehicle flag 

= 0, vehicle is reusable 
^0, vehicle is expendable 

28 TREFT Upper stage refurb time in days 

29 SREFT Shuttle refurb time in days 

30 PADT Sum of payload integration, Shuttle-Tug 

integration, travel to pad, and launch 
checkout times in days 
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NAME 


DESCRIPTION 


31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

41 

42 

43 

44 

45 

46 

47 

48 

49 


PADT 

Number of days delay between decision to 
fly and actual launch (integration, move to 
pad, preflight check) 

DAYS 

Number of days the upper stage can remain 
in orbit 

DV 

Delta velocity required to get from parking 
orbit to final orbit 

FISP 

for the upper stage 

WD 

Inert structural weight of upper stage 

WPNU 

Weight of unused propellant of upper stage 
remaining at the end of maneuvers 

WCONS 

Maximum weight of upper stage plus pay- 
loads (derived from either upper stage or 
Shuttle considerations) 

lORB 

Points- to current orbit 

NQ 

Number of payloads going to the lORB 
orbit 

RA 

Radius of apogee of final orbit 

VCO 

Circular velocity of final orbit 

RO 

Radius of the Earth 

PI 

Period of the final orbit in hours 

RTFLG 

Retrieve payload flag 

=0, no retrieve 
/O, retrieve 

PA DEN 

Maximum total length of multiple payloads 
on any flight 

FLYT 

Total flight time of current flight 

WAIT 3 

The delay time between an NRU failure and 
the availability of a replacement satellite 

NEXIT 

SEPS status flag returned from SEPS per- 
formance routine 

MSEP 

Era.se flag used in SEPS performance 
routine 
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SETS AND QUEUES 


ARRAY NO 

NAME 

DESCRIPTION 

50 

FNEWS 

Pointer to the first item in the set NEWS 

51 

FFRS 

Pointer to the first element in the set FRS 

52 

LFRS 

Pointer to the last element in the set FRS 

53 

FMES 

Pointer to the first item in the set MES 

54 

FLOAD 

Pointer to first payload in current loading 
queue 

55 

LLOAD 

Pointer to last payload in current loading 
queue 

56 

— 

Spare 

GLOBAL VARIABLES AND 

CONSTANTS 

ARRAY NO 

NAME 

DESCRIPTION 

57 

EXMOD 

Expendable model flag 

58 

DELTA 

Indication of redundancy 

0 implies group is out of service 
+3000 implies group is still in service 
-3000 implies one more failure and 
group IS out of service 

59 

EXTUG 

A flag to expend the upper stage because 
payload is too heavy for reusable stage 
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ORBIT TABLE 


ARRAY NO 

NAME 

DESCRIPTION 

60 

NORBS 

Number of orbits the simulation can deploy 
to and service 

61 

ORBID 

Name of orbit 

62 

ORBDV 

Delta V from parking orbit to final orbit 

63 

ORBPD 

Final orbit period m hours 

64 

ORBRA 

Apogee radius of final orbit in feet 

65 

ORB VC 

Equivalent circular orbit velocity in 
feet/s econd 

66 

ORBTM 

Total flight time for vehicle to leave 
launch pad and return to ground 

67 

ROUP 

Name of required upper stage or blank 

68 

RQSEP 

Name of required SEPS vehicle 

69 

RQSUT 

Name of required Shuttle vehicle. 

70 

PQUE 

Pointer to first payload in loading queue 
assigned to current flight 

71 

NL 

Number of payloads currently assigned to 
a launch to each orbit 

72 

ANMD 

Number of modules on current flight to the 
orbit 

73 

W 

Percentage propellant remaining on this 
flight If negative, the payload group is 
too heavy or long 

74 

NMDFL 

Space available 

75 

FORB 

List of pointers to first item in list of pay- 
loads in loading queue available for launch 

76 

LORE 

List of pointers to last item in list of pay- 
loads in loading queue available for launch 

77 

DVl 

Delta V used in first burn of two-burn seq- 
uence (trans-kick) 

78 

EXORB 

Flag used to indicate the upper stage ser- 
ving this orbit IS being used in an expend- 
able or reusable mode 

79 

-- 

Spare 
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PAYLOAD TABLE 


ARRAY NO 

NAME 

DESCRIPTION 

80 

IL 

Maximum number of payloads that can be 
on any vehicle 

81 

FLTIM 

Flight time for each payload on current 
flight from launch to final orbit position 

8Z 

ILOAD 

Pointers to the loading queue for the pay- 
loads in the current flight 

83 

PANGL 

Phase angles between the payloads in the 
current flight 

84 

-- 

Spare 
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VEHICLE TABLE 


ARRAY NO 

NAME 

DESCRIPTION 

85 

NVEH 

Number of different types of vehicles (or 
stages) to be used in the simulation 

86 

NAMEV 

Name of vehicle. 

87 

DAYSV 

Number of days the vehicle can remain 
aloft 

88 

ISPV 

I of vehicle or stage 

89 

MDV 

Inert structural weight of vehicle or stage 

90 

WPNUV 

Weight of unused propellant remaining in 
stage at end of maneuvers 

91 

WCONV 

Maximum weight of vehicle 

92 

REF TV 

Stage refurb time in days 

93 

EXPV 

Expend stage flag, if not zero, stage is to 
be expended 

94 

PAYLV 

Maximum total length of payload to be 
placed on this vehicle. 

95 

IDV 

Space vehicle available 

96 

NS TAG 

Number of stages comprised in this vehicle 

97 

SOLID 

Solid stage flag Stage is solid if flag 
non-zero 

98 

— 

Spare 

99 

— 

Spare 
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VEHICLE FLEET STATISTICS 


ARRAY NO 

NAME 

DESCRIPTION 

100 

NYEAR 

Number of years for accumulation of 
vehicle statistics 

101 

SUTFY 

An array used to collect the number of 
Shuttle flights in each year 

102 

SUM90 

An array used to collect the number of 
Tug flights in each year. 

103 

MAX90 

An array used to keep the maximum values 
of SUTFY over all Monte Carlo cycles 

104 

MIN 90 

An array used to keep the minimum values 
of SUTFY over all Monte Carlo cycles 

105 

TUGFY 

An array used to collect the number of 
Tug flights in each year. 

106 

SUM39 

An array used to keep the total number of 
Tug flights in each year for all Monte 
Carlo cycles 

107 

MAX39 

An array used to keep the maximum values 
of TUCFY over all Monte Carlo cycles 

108 

MIN39 

An array used to keep the minimum values 
of TUCFY over all Monte Carlo cycles 

109 

SEPFY 

An array used to collect the number of 
SEPS flights in each year 

110 

SUMS 6 

An array used to keep the total of all 
SEPS flights in each year for all Monte 
Carlo cycles 

111 

MAX86 

An array used to keep the maximum values 
of SEPFY over all Monte Carlo cycles 

112 

MINS 6 

An array used to keep the minimum values 
of SEPFY over all Monte Carlo cycles 

120 

NSHUT 

Number of Shuttles in fleet 

121 

VSHUT 

Shuttle availability array 

122 

IS HUT 

Pointer to currently available Shuttle 


113 - 119 -- Spares 


B-9 













ARRAY NO 

NAME 

DESCRIPTION 

123 

MFSUT 

Minimum number of Shuttle total flights in 
any Monte Carlo cycle 

124 

IFSUT 

Total number of Shuttle flights over all 
Monte Carlo cycles 

125 

NFSUT 

Maximum number of total Shuttle flights 
in any Monte Carlo cycle 

130 

NTUG 

Number of Tugs in fleet. 

131 

VTUG 

Tug availability array 

132 

ITUG 

Pointer to currently available Tug. 

133 

NTFLT 

Minimum number of Tug total flights in 
any Monte Carlo cycle 

134 

ITFLT 

Total number of Tug flights over all Monte 
Carlo cycles 

135 

MTFLT 

Maximum number of total T ug flights in 
any Monte Carlo cycle 

140 

NSEPS 

Number of SEPS in fleet 

141 

VS EPS 

SEPS availability array 

142 

ISEPS 

Pointer to currently available SEPS 

143 

NFSEP 

Minimum number of SEPS total flights in 
any Monte Carlo cycle 

144 

IFSEP 

Total number of SEPS flights over all 
Monte Carlo cycles 

145 

MFSEP 

Maximum number of SEPS flights in any 
Monte Carlo cycle 











MODULAR TABLE 


ARRAY NO 

NAME 

DESCRIPTION 

150 

MITAB 

Maximum number of modules 

151 

MNAME 

Name of module 

152 

ALPF 

Weibul parameter ot for failure 

153 

BETAF 

Weibul parameter ^ for failure 

154 

TTFMD 

Truncation time for failure 

155 

ALPW 

Weibul parameter a for warning 

156 

BETAW 

Weibul parameter yg for warning 

157 

TTWMD 

Truncation time for warning 

158 

MODWT 

Module weight in pounds 

159 

MDVOL 

Module volume in cubic feet 

160 

MCLAS 

Module classification 

161 

MDCNT 

Count of modules replaced during a Monte 
Carlo cycle 

162 

S121 

Sum of MDCNT over run - used to find 
average 

163 

X121 

Maximum value of MDCNT 

164 

N121 

Minimum value of MDCNT 

165 

NOWAR 

Count of module warnings during a Monte 
Carlo cycle 

166 

S125 

Sum of NOWAR over run - used to find 
average 

167 

X125 

Maximum value of NOWAR 

168 

N125 

Minimum value of NOWAR 

169 

NOFAL 

Count of module failures during a Monte 
Carlo cycle 

170 

S129 

Sum of NOFAL over run - used to find 
average 

171 

X129 

Maximum value of NOFAL 

172 

N129 

Minimum value of NOFAL 

173 - 179 

— 

Spares 
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SATELLITE TABLE 


ARRAY NO 

NAME 

DESCRIPTION 

180 

SITAB 

Maximum number of satellites 

181 

SNAME 

Satellite name 

182 

SWT 

Satellite weight in pounds 

183 

SVOL 

Satellite volume in cubic feet 

184 

PRIOR 

The priority of the satellite (1-6} 

185 

INCL 

The orbit inclination 

186 

ORBIT 

Orbit apogee-perigee key 

187 

TTSAT 

Satellite termination time m years 

188 

PTSAT 

Premature termination time 

189 

EXSAT 

Flag to indicate expendable satellite 

190 

NRSAT 

Flag for non- replaceable satellite 

191 

NMODS 

Number of modules for this satellite 

192 

POLDN 

Policy indication of action to be taken at 
the end of satellite life 

193 

SORTE 

If not zero, this is the number of days 
duration of a Sortie flight. 

194 

FMDS 

Pointer to first module in module set 
belonging to this satellite. 

195 

LMDS 

Pointer to the last module in module set 
belonging to this satellite 

196 - 199 

— 

Spares 
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SATELLITE SYSTEM TABLE 


ARRAY NO 

NAME 

DESCRIPTION 

200 

STSTB 

Maximum number of satellite systems 

201 

SYNAM 

System name 

202 

TTSYS 

System termination time 

203 

PTTSY 

Premature termination time 

204 

NS AT 

Number of satellites in system 

205 

FSAT 

Index to first satellite in array SYORB 
belonging to this system. 

206 

LSAT 

Index to the last satellite in the array 
SYORB belonging to this system 

207 

STAT 

The system status 

208 

NFUP 

Number of active satellites required to 
have system active 

209 

TGOSY 

Time at which system is to be terminated 

210 

SYLF 

Total weight factors or flights in support 
of this system (used for averaging) 

211 

XSYLF 

Maximum value of SYLF in any one Monte 
Carlo cycle 

212 

NSYLF 

Minimum value of SYLF in any one Monte 
Carlo cycle 

213 

BEGSY 

Time at which system was initialized 

214 

HALSY 

Time at which system was terminated 

215 

TLASY 

If positive, the time that the system be- 
came active If negative, inactive system. 

216 

SDTSY 

Sum of all the time intervals the system 
IS up 

217 

PERSY 

Total of percentages of system availability 
over all Monte Carlo cycles 

218 

X200 

Maximum percentage of system avail- 
ability in any one Monte Carlo cycle 

219 

N200 

Minimum percentage of system avail- 
ability in any one Monte Carlo cycle 


B-13 








ARRAY NO 

NAME 

DESCRIPTION 

2Z0 

DNTSY 

Total of all delay time intervals incurred 
while system was being restored to ser- 
vice 

221 

C208 

Count of the number of times the system 
was delayed in being restored to service 

222 

X208 

Maximum delay interval incurred while 
system was being restored to service 

223 

N208 

Minimum delay interval incurred while 
system was being restored to service 

224 - 229 

-- 

Spares 
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SATELLITES IN ORBIT TABLE 


ARRAY NO 

NAME 

DESCRIPTION 

230 

SYORB 

Maximum number of satellites in orbit 

231 

ITSAT 

Index for this satellite in satellite array 

232 

ITSYS 

Index for the system in the system array 
to which this satellite belongs 

233 

SSTAT 

Satellite status 

234 

PHASE 

Phase angle of this satellite 

235 

ATIME 

Time satellite arrives in orbit Used to 
block failures and warnings of earlier 
satellites 

236 

DTIME 

Spare variable 

237 

MARKS 

Pointer to event SATDN for this satellite 

238 

MARKU 

Pointer to event NWSAT for this satellite 
{set up by SAVER) 

239 

MARKD 

Pointer to event RETRI for this satellite 
(set up by SAVER) 

240 

LFSAT 

Sum of weight factors for this satellite 
over a Monte Carlo cycle 

241 

SUMSL 

Total of LFSAT over all cycles (used for 
averaging) 

242 

MAXSL 

Maximum value of LFSAT 

243 

MINSL 

Minimum value of LFSAT 

244 

TOO 

Time when satellite is to be terminated- 

245 

BEGST 

Time at which satellite is initialized 

246 

HALST 

Time at which satellite is terminated 

247 

TLAST 

If positive, the time that the satellite be- 
came active If negative, inactive 
satellite 

248 

SDTST 

Sum of all the time intervals the satellite 
is up in a Monte Carlo cycle 
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ARRAY NO 


NAME 


DESCRIPTION 


249 

PERST 

Total of percentages of satellite availa-i 
bility over all Monte Carlo cycles. 

250 

X216 

Maximum percentage of satellite availa- 
bility in any one Monte Carlo cycle. 

251 

N216 

Minimum percentage of satellite availa- 
bility in any one Monte Carlo cycle. 

252 

DNTST 

i 

Total of all delay time intervals incurred 
while satellite was being restored to 
service 

253 

C223 

Count of the number of times the satellite 
was delayed in being restored to service 

254 

X223 

Maximum delay interval incurred while 
satellite was being restored to service 

255 

N223 

Minimum delay interval incurred while 
satellite was being restored to service 

256 

SATLF 

Sum of weight factors for deploy-only mode 
{no service) for this satellite over a Monte 
Carlo cycle 

257 

S227 

Total of SATLF over all cycles (used for 
averaging) 

258 

X227 

Maximum value of SATLF 

259 

N227 

Minimum value of SATLF 

260 

NPOS 

Number of satellites currently at each 
satellite position in orbit 

261 

NDEP 

Number of satellites deployed to each 
satellite position in orbit 

262 

FMOD 

Pointer to first module in module set be- 
longing to this satellite in orbit 

263 

LMOD 

Pointer to last module in module set be- 
longing to this satellite in orbit 

264 - 269 

— 

Spares 
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VEHICLE AVAILABILITY STATISTICS 


ARRAY NO 

NAME 

DESCRIPTION 

270 

NVS 

Number of vehicle types 

271 

CVA 

Number of times in a Monte Carlo cycle a 
vehicle type became unavailable 

272 

TCVA 

Total of CVA over all cycles (for aver- 
aging) 

273 

XCVA 

Maximum value of CVA 

274 

MCVA 

Minimum value of CVA 

275 

VDATE 

Unavailability interval for vehicle type 



0, vehicle type available 

negative sum of dates vehicle 
type became unavailable 
+ , interval of unavailability 

276 

VTD 

Total of VDATE over all occurrences 

277 

XTD 

Maximum value of VDATE 

278 

MTD 

Minimum value of VDATE 

279 

-- 

Spare 
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UPPERMOST STAGE STATISTICS 


ARRAY NO 

NAME 

DESCRIPTION 

280 

CTUG 

Total number of Tugs used as uppermost 
stage on each orbit 

281 

WTUG 

Total weight of payload delivered on Tugs, 
etc 

282 

CSHUT 

Total number of Shuttles, etc. 

283 

WSHUT 

Total weight of Shuttles, etc. 

284 

CSEPS 

Total number of SEPS, etc 

285 

WSEPS 

Total weight payload SEPS, etc 
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APPENDIX C SAMPLE PRINTOUT 


This appendix contains a small sample run which can be 
used to verify the basic operations of the program There are 20 pages 
of computer output for a very small data case. This sample can be 
executed in 3 seconds on the CDC 7600 computer at The Aerospace Corpo- 
ration, El Segundo, California, and in 12 seconds on the UNIVAC 1108 
computer at the NASA Computer Facility, Slidell, Louisiana. 

The appendix consists of the following parts 


a. 

Pages 2-4 

Listing of the entire input data deck. 

b. 

Pages 5-6 

SIMSCRIPT print of the initialization 
data deck. 

c. 

Pages 7-8 

Program print of the input data cards 

d. 

Page 9 

Summary of unused input data 

e 

Pages 10-12 

Chronological time history of the first 
Monte Carlo cycle of the run. 

f. 

Pages 13-14 

Chronological time history of each satel- 
lite position This IS a rearrangement of 
most of the information on pages 10-12 

g- 

Pages 15-21 

Statistical summaries of the 25 Monte 
Carlo cycles in this run. The summaries 
are for vehicles, orbits, systems, satel- 
lites, and modules 
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WAIT 3 

43 

HO HRALIS 

20 

NO PL ON VEH 

20 

NO OF OIFF VEH 

30 

NO vrTTn'kun" 

20 

MO OF SHUTLS _ 

10 

NO OF TUGS 

10 

NO OF SEPS 


19 


NO OF MOOS 



INITIALIZATION CAROS 

1 2 ^ ^ h 5 6 7 A 

X2.3-A567A- 9 0 12 3» 5 6 7a9 1i 1 23.4 567 a CQI 234567A9 0 J L 2 . 34 567 89 01 23 45 6 789 4-12 34 S67 a 9 0 l2 3 »5 6 769 fl 
151 172 1 Z 19 150 

173 179 0 Z ^ 

180 OR 5 NO OF SATS 

l ai 1 95 1 Z 5 . 1 8D 

196 199 0 Z 

200 Q R 4 NO OF SYSTHS 

201 223 1 Z 4 200 

_224-22a-0 Z 

230 OR 15 NO SAT-POS 

231 263 i Z 15 230 

264 269 0 7 

-2.70 Q-_S 3 NO TY6FS llf.H — 

271 276 1 Z 3 270 

279 0 Z 

280 285 1 Z 43 60 


INITIALIZATION TERMINATED WITHOUT ERROR. EXECUTION CONTINUED 



input OftTfl 


0 

1 

-J 


3 V€HICLPS INPUT 
NflNE 06Y3 ISP HOY HPNU 
TUG 7.0 tvOi+.a 52?3 0 

SHIL n*il 0.0 O.Q 

sHTti 0.0 n.o 0.0 

3 nRPITS input 

NAME OV PFRICO RA 

SNC/fl 13382.0 24.0 22763.0 

1-1728 0.0 u.O U 0 

SO RT 0.0 0 . 0.0 


HCONV »EFT EXP 
950.0 63538.0 

Q.O 65000. C 
O.Q 63538. D 

YC UPPER SEPS 
iClOO.O TUG 
C.C 


0.0 


length 
14.0 
0.0 
0. J 

SHUTTLE 
Sh TLl 
SHTLI 
SHTu 


NSATGE 

O.Q 

0.0 

0.0 


0.0 

0.0 

Q.O 


SOLID 
60. C 
60. 0 
60. 0 


10 


0 

0 

0 


0 

o 

0 


NAME 

ALPHA F 

BETA F 

TT 

ALPHA H 

BETA H 

HT 

YOL 

AYCS2 

14. a C 

1.00 

10.00 

0. LO 

1.00 

94.00 

0.00 


5.10 

1.02 

5.00 

0.00 

1.00 

119.00 

0.00 

OPl 

18.93 

1.00 

10.00 

0.00 

1.00 

103.00 

O.OC 

EPS! A 

21. SI 

C.99 

4 . 0 L 

0. Ou 

l.QQ 

IIQ.QO 

a. on 

EP52 

21 43 

0.99 

S.Ou 

o.co 

1. 00 

287.00 

0.00 

EPS3 

99.99 

1.00 

5.00 

&.00 

1.00 

112. OC 

O.OC 

ASTlCl 

15.48 

1.00 

5.0Q 

0 00 

1.00 

376.00 

O.OC 

AYCS3 

14.80 

l.QQ 

10.00 

0.00 

1.00 

241.00 

HLQH 

AVCS5 

6.47 

1.15 

10.00 

0. 00 

1.00 

123.00 

0.00 

AVCS7 

14.35 

1 02 

7.00 

0.00 

1.03 

112,00 

O.OC 

GNl 

6.17 

1.00 

10.00 

0.00 

l.GO 

173.00 

Q.OO 

EU2 

7,13 

1.00 

10,00 

a. 00 

1.00 

914.00 

o.ao. 

TTCl 

14.67 

1 10 

10.00 

0. QQ 

1. jQ 

112.00 

o.co 

NNOll 

26 .95 

1.00 

10.00 

Q.OO 

1.00 

377.00 

0.00 

NND12 

18 .36 

1.03 

10. OG 

0.03 

1.03 

548.00 

Q.OO 

!^J1C 

99 .J 9 

1.00 

10.00 

0 ■ i) Q 

l.M 

6S3.D0 

o.oa 

NNNDl 

28.01 

1.00 

10.00 

0.00 

l.QQ 

1926.00 

0.00 

MODULE 

0.00 

0.00 

999.00 

0.00 

l.GO 

0.00 

O.OQ 

MODI 

0.00 

l.GO 

O.OC 

0.00 

1.00 

0.00 

0.00 


OULSS- 






NAIF 

5 SATELLfTFS INPUT 
WT VOL PRIOR 

INCLINATICN ORBIT 

MODULES 

SAT TT POLICY 

AST lA 

1373. 

13. 

0. 

0. 

1-1728 

1 


20. 

2 0. 


MODI 

1 








“sfiiT"' 

2491. 

3. 

0. 

0, 

SNC70 

13 


20. “ 

■'2 o'.' 


NASTIC 

X AVCS3 


AVCS5 

AYCS7 


AYCS7 

AVCS7 

AVCS7 


GNl 

GN2 


TTC5 

OPl 


EPSIA 

ASTlCl 


HHOIA 

■iTT? . 



JL. 

- . 


ZO 


Zfl.,.__ 

Z_ . _J1U 


NNNOl 

X AVCS? 


AVCS5 

AVCS7 


AYCS7 

AVCS7 

AVCS7 


GN2 

TTCl 


DPI 

EPS2 


EPS2 

EPS2 

EPS2 


EPS2 

EPS2 


EPS3 

EPS3 


NNOli 

NN012 


WNDIR 

5772 . 

Aa 

JI, 

fl » 

SJiCZO.. . 

ZA 


_ 20,. , _ 

2 A, 


NNNOl 

X AYCS2 


AYCSS 

AYCS7 


AYCS7 

AVCS7 

AVCS7 


GN2 

TTCl 


DPI 

EPS2 


EPS2 

EPS2 

EPS2 


EPS2 

EPS2 


EPS3 

EPS3 


NNUll 

NN012 


■ SORT.? 

10M.Q, 

60, 

a. 

0. 

SORT 

1 


la. 

0 . . 


MODUL«^ 

X 









4SYSTF('S 

INPUT 








NAME 

milT 

„ SYS TT 

■ SAT 

-PHASLE SAI 


PHASE 

SAT PHASE 

ASTIA 

1 1 

20.00 


ASTIA 

0.0 


0. 0 


0 . 0 

A ST to 

2 2 

7.00 


Asrio 

-60.0 ASTID 


-80.0 


O.Q 




NN01A8 


4 

20.00 

NNOIA 

-40.0 

NNOIB 

-180.0 

NNDIA 

-40.0 



NNOie 

-180.0 


0.0 

0.0 

1 

_ ..1.2...00 

SORT? 

0-.JJ. 

... 

-lU-Q — 


O—O- 


ASTID 

NNOIAB 

_soaiz_ 


1983. 09000 
1980. 33000 
-1-982.. 09000 


ASTIO 
NNDl AB 


0 0.00000 0 

ME UPGRADE SCHEDULES INPUT 

0 


1983.090Qd 0 
1980.33000 3 

0.00000 0 


NNOIAB 


0.00000 0 
1960.33000 4 
0.00000 0 


NNOIAB 


0.00000 0 


0 . 

1980. 
0- 

0 . 


00000 

49000 

00000 


0 


0 . 0 . 0 



SYNOPSIS OF INPUT 
UNUSED SYSTEM - ASTIA 

P .ROBI.F H US F n ft . SA.T. F . U ,..nF/ S Y S TFH .EOSLXXaUS QIJ.T -JOE -AUAXLABLE -J 15 - 

PROBLEM USED 3 SYSTEMS OUT OF AVAILABLE 4 
UNUSED SATELLITE - ASTIA 

PROBLEM USED L SATELLITES OUT OF AVAILABLE 5 

UNUSED .M n nil.l..F-. = i MOni. 

PROBLEM USED 18 MODULES OUT OF AVAILABLE 19 


0 

1 

•vO 


I 



-10 


riHE 


SYSTEM 


CHRONOLOGICAL TIME HISTORY OF 9ASE CYCLE 
STATUS SATELLITE STATUS MODULE STATUS YEHICuE STATUS 


1960. 3.28 
1 q nn - 

— LAUNCH NOW 
1990. 3. 26 

- iq an. 3 .?b 
"LAUNCH NOW 
1980. 3.28 

1 gap ■ „ 

1980. 3.28 
1980 . 4.1A 
1960 . 4.14. 

1 9611 . At 1 4 
1980. 4.14 
1980. 5.26 
--LAUNCH NOW 
— laaJL.- S..26 — 


NN01A9 3 OUT 
JJNaiAB — ^ auT 
— SHUTTLE NO. 
NNDIAB 3 OUT 

1 QUI 
-- SHUTTLE NO. 
NNDIAR 2 OUT 


NNOI AB- 
NNO1A0 


KNDIA available 

umta. AUAJUU3LE- 

20 TUG NO. 10 SEPS NO. 


3 JIUI 
2 OUT 


NNOIAB 4 OUT 
-- SHUTTLE NO. 
^.NNOIAB. 1 HUT 


NNOIA 

- KNOIJl 
19 TUG NO. 
NNDIB 

_ _ NNOJ.A 

NNDlB 


NND10 
20 TUG NO. 
NNJUA 


LAUNCHED 

Aya u API F 
9 SEPS NO. 
LAUNCHED 

_ HK-.- 
OK 


available 
10 SEPS tc. 

_ LAUNCMEC 


0 WEIGHT = 5772. LENGTH 


8 . 0 - 


0 HEIGHT = 


5772. LENGTH 


8 . 0 - 


TUG 

0 HEIGHT = 5772. LENGTH = 


SHUT 20 REFURBISHED 
TUG 10 REFURBISHED 
-SHUT 19 REFURBISHED 


9 REFURBISHED 


3.0- 


O 


1960. 5.26 
1980. 6.11 
■ 1 9 80. 6 .11 


NNDIAB 1 OUT 


1980. 7.16 
1980. 7.22 
— LAUNCH NOW 


1930. 8.26 
1980. 8,26 


NNOIAB 1 
NNOIAB 3 
-- SHUTTLE NO. 


OUT 

OUT 


NNO 1 A E 
NNOIAB 


OUT 

OUT 


NKDIA 


NNOIA 
NNOIA 
20 TUG NO. 

NNDIA 

NNOIA 


OK 


OUT 
OUT 
iO SEPS NO. 


OUT 

OUT 


TTCl 

TTCl 

0 HEIGHT 

T TCI 
TTCl 


OUT 

OUT 


SHUT 

-IU6_ 


20 REFURBISHED 
-10— R££UR8ISHEQ 


6396. LENGTH 


16.0- 


LAUNCHEO 

LAUNCHEO 


1980 . 

8.26 

NNOIAB 

1 

OUT 

NNOIA 


OK 

TTCl 

OK 

1980. 

8.26 

NNDIAB 

3 

OK 

NNDIA 


OK 

TTCl 

OK 

1930. 

.1.980- 

9. 11 
q - 1 1 









1981. 

0.22 

NNOIAB 

4 

OUT 

NNDIB 


OUT 

NN012 

OUT 

1981, 

2. 7 

NNOIAB 

3 

OU1 

NNOIA 


OUT 

AVCS5 

OUT 

1981. 

3. 1 

NNOIAB 

2 

OUT 

NNOie 


OUT 

AVCS7 

OUT 

i at 1 Kin M MPU 

. "—SJiUXILF 

JlJl. 

?n Ttir. i\ir>. , 

1 n 

_SFPS WO. 0 HPIGHT 

= 1183. 

1981. 

3. 22 

NNOIAB 

4 

our 

NNOIB 


OUT 

NND12 

LAUNCHEO 

1981. 

3.22 

NNOIAB 

? 

OUT 

NNDIB 


OUT 

AVCS7 

LAUNCHEO 

1981. 

3.21’ 

NNDIAB 

3 

OUT 

NNOIA 


OUT 

AVCS5 

LAUNCHEO 

■ l9?l7‘ 

3.22 

NNDIAB 

"4 

Tuf 

~ nno"ib"”“ 

“ 

OK 

NI^12 " 

OK 

1981. 

3.22 

NNOIAB 

2 

nui 

NNDIB 


OK 

AVCS7 

OK 

1981, 

3. 22 

NNOIAB 

3 

OK 

NNDIA 


OK 

AVCS5 

OK 

—1331-.- 









.. 

1981. 

4. 7 









1981 . 

5. 0 

NNOIAB 

2 

OUT 

NNDIB 


OUT 

AVCS7 

OUT 

1981. 

5. 1 

NNOIAB 

4 

OUl 

NNDIB 


OUT 

AVCS7 

OUT 

_L98L^_ 

-5.-3-, 

„ NNfH aq 

. Ji-OLLI 



our 

3P1 _ 

JQUI 

1981. 

7. 5 

NNOIAB 

4 

OUT 

NNOie 


OUT 

AVCS5 

OUT 

--LAUNCH NOW 

-- SHUTTL‘D 

NO. 

20 TUG NO. 

ip 

SEPS NO. C HEIGHT 

= 850. 


SHUT 20 REFURBISHED 


J_£NjGXH_=_ 


8 . 0 - 


TUG 


10 REFURBISHED 


LENGTH = 


8 . 0 - 



o c 

p § 


1981. a. 0 
1981. 8. 0 
1Q31. fl. n 
1981. 8. 0 

NN01A9 
NND1A8 
_ iiMLULE- 
NNOIAB 

2 OUT 
A OUT 
i-ULLI 
A OUT 

NNOIB 

NNOIB 

HNDIB 

NNOIB 

OUT 

OUT 

OUT 

OUT 

AVCS7 

AVCS7 

OPX- 

AVCS5 

LAUNCHED 

launched 

LAUNCHED; - 
LAUNCHED 


1981. 8. 0 

NNOIAR 

2 OUT 

NNOIB 

OK 

AVCS7 

OK 


. - 1 SAL. a- n_ 

...NNO.IAB- 

Jt- HUX 

_ . .NNniB 

OUT 

Jivesz 

QE 


1981. 8. 0 

NNOIAS 

A OUT 

NNOIS 

OUT 

OPl 

OK 


1981. 8. C 

NNOIAB 

A OK 

NNOIB 

OK 

AVCS5 

OK 


1981. 8.15 







SHUT 

_19AL_.a-JL5 







TUG 

1981.11.20 

NNO1A0 

1 OUT 

NNDIA 

OUT 

NND12 

OUT 


1982. 1. 2 

SORT? 

1 OUT 

SORT? 

AVAILABLE 




— LAUNCH NON 

— SHUTTLE NC. 

20 rue NO. 

0 SEPS NO 

0 WEIGHT 

= 10000. 

LENGTH 


_LSLa2-._l._2- 


1982. 1. 
1932. 1. 
...1.98? 


2 
9 

L.2i 


<;flRT7 

'sOPTf 

SOR’7 


1 OUT ...SOii.T.7 


OK 

N6 


1982. 2.16 
--LAUNCH NON 
1932. 2.20 


NN01A8 A OUT 
— SHUTTLP NO. 
NN01A3 A OUT 


29 


SORT? 

SORT? 

~ “NNO’! B 
TUG NO. 
NN013 


10 


, . i.AjaN£H£3 
'oK 

REHUVEO 

ouf 

SEPS NO. 
OUT 


20 REFUR8ISHE0 
iO-_RERURa-LSH£0 


60. 0- 


EPS2 


OUT 


SKIT .20 RFF-XigaiSHFn 


e HEIGHT = 1235. LENGTH = 


EPS 2 


- nNUTart_ i imi a „UUJL .. < 

1982. 
1982. 
1 q«?. 

2. 20 
2. 20 
7. 6 

NNDlAP 

NNOIAB 

A 

1 

OUT 

OK 

NNOIB 

NNOIA 

OK 

OK 

EPS2 

NN012 

AVCS7 
EPS2 
FPS? - 

1982. 

1982. 

1982. 

AS82. 

3. 5 
3. 17 
6. 13 
6. 13 

NNOIAB 
NNOIAB 
NNHi aq 

3 

2 

OUT 

OUT 

OUT 

NNOIA 
NNDIS 
NNOl B - 

OUT 

OUT 

OUT 

—LAUNCH NOH 

— SHUTTLE 

NO. 

20 TUG NO. 

10 SEPS NO. 

0 weight 

1982. 

6. 17 

NNOIAB 

2 

OUT 

NN013 

OUT 

EPS2 

1982. 

6.17 

NNDIAB 

2 

OUT 

NNOIB 

OUT 

£PS2 

1982.- 

..6^.17 .. 

NNH1 Afi 

-3. 

OUT 

- NNOIA- 

_ -QUl 

■A«r.S7- , 


LAUNCHED 
LAULNCHEU - 


3.0- 


OK 

OK 


OUT 
OUT 
OILI 

- 1036. 

LAUNCHED 

launched 

. LAtlhlCHED. 


SHUT PfI PFFllgRrSHFfl 


TUG 


10 REFURBISHED 


LENGTH = 


8 . 0 - 


1982. 6. 17 

NNDIAB 

2 

OUT 


NNOIB 

OUT 

£Ps2 

OK 





1982. 6.17 

NNOIAS 

2 

OUT 


NNOIB 

OK 

EPS2 

OK 





1982. 6.17 

NNOIAB 

-3- 

OK 


NNOIA.. 

_ OK 

AVCS7 

-UK 





1982. 7. 3 










SHUT 

2Q 

REFURBISHED 

1982. 7. 3 










TUG 

lU 

REFURBISHED 

1982. 9. 6 

NNOIAB 

A 

OUT 


NNOIB 

OUT 

AVCS2 

OUT 





— i.AUNCH NON 

— SHUTILE 

NO. 

?n 

TUG NO- . 

1 n 

fl WFIGHT 

— 


LENGTH. 

n 

a.n 

1983, 0. 6 

NNOIAB 

A 

OUT 


NNO'ie 

OUT 

AVCS2 

LAUNCHED 




1983. 0. 6 

NNOIAB 

A 

OK 


NNOIB 

OK 

AVCS2 

OK 





1983 . 0. 21 










SHUT 

za 

REflXRBIS.H£Jl„_ 

1983, 0,21 










TUG 

10 

REFURBISHED 

1933. 1. 2 

ASTID 

P 

OUT 


ASTIO 

AV ALLABLE 







1983. 1. 2 

ASTIO 

1 

OUT 


ASTIO 

AVAILABLE 







1983. 7.27 

NN01 AB . 

_2 

OUT 


NNni 3 - 

mji 

-A.VCE2 

Dili 





— LAUNCH NON 

— SHUTTL 

<T 

NO. 

20 

TUG IiO, 

1C SEPS NO. 

il WEIGHT 


A982. 

LENGTH 

= 

6.0 

1983. 2.27 

ASTIO 

2 

OUT 


ASTIO 

launched 







1983. 2.27 

ASTiO 

1 

OUT 


ASTID 

LAUNCHED 







1983, 2,27 

ASTIO 

T 

OUT 

■ - 

ASTIO 

OK 

■ 






1983. 2.27 

ASTIO 

1 

OK 


ASTIO 

OK 








1963. 3.12 
1963, 3.12 
1963. 3.22- 


1983. 5. 6 
— LAUKCH NOW 
1983. 5. 9 
l-9A3^-5. 6 ... 




NNOIAB 3 OUT 

— shuttle no. 

NNOIAB 2 OUT 


_ -NNXXia 
NNOIA 
20 TUG NO. 
NNOIB 
— HN Oia.. 


— joui 
OUT 

10 SEPS NO. 
OUT 

OUT 


SHUT 

TUG 


20 REFURSISKEO 
10 REFURaiSHEO 


.£PSZ~. - OUT 

AVCS7 OUT 

0 HEIGHT = 781. LENGTH = 8.0- 

AVCS2 LAUNCHED 

LAUNCHED 


1983. 5. 6 
1993. 5. 6 
1-SH3. 9.21 


NNOIAB 2 OUT 
NNOIAB 4 OUT 


1983. 5.21 
1983. 6. 9 
— LAUNCH NOW 
■1-9.8 3.,.. 8. 6 


1983. 6. 6 


NNOIAB 2 OUT 
— SHUTTLE NO. 
NNOIAB. _2~OU.I 
NNOIAB 3 OUT 


NNOIB 

NNDIB 


NNOIB 
20 TUG NO. 
- NNDIS 
NNDIA 


ON 

OK 


OUT 

10 SEPS NO. 

CUT 

OUT 


AVCS2 

EPS2 


EPS2 ^ , 
0 HEIGHT 
EPS2-- 
AVC37 


OK 

OK 


OUT 


SJdU-L— -.2a_B 
TOG 10 REFURBISHEO 


799. LENGTH = 


8 . 0 - 


LAUNCHED 


1983. 8. 6 
1-9.83, -8. 6 
1983. 8.19 
1983. 8.21 
1983. 8.21 
198.3. Q.?7 
1983.10. 7 
— LAUNCH NCH 
1983.11.19 


NNOIAB 2 OUT 
-OJC-. 
ASTIO 1 OUT 


MNini AH L nuT 
NNOIAB 3 OUT 
— • SHUTTLE NC. 
ASTIO 1 OUT 


NNOIB 

NNOIA 

ASTIO 


- XNOIB 
NNOIA 
20 TUG NO. 
ASTIO 


OK 

.-QK-. 

OUT 


- OUI - 
OUT 

10 SEPS NO. 
OUT 


EPS2 

AVCS7 

TTC5 


OK 

CK. 

OUT 


SHUT 20 REFURBISHtO 

TUG 10 REFURBISHED 

AA/CS7 OUT - 

AVCS5 OUT 

0 HEIGHT = 519. LENGTH = 3.0 

TTC5 LAUNCHED 


' 1983.11.19 

ASTIO 

1 OK 

ASTIO 

OK 

1984. 0. 

0 

NNOIAB 

3 OUT 

NNDIA 

NG 

1984. 0. 

0 

NNOIAB 

2 OUT 

NNOIB 

NG 

i Q ft L , f> . 

_ 0 _ - 

NNini iiq 

_t -OUT- 

NHQi fl 

NG 

1984. 0. 

0 

NNOIAB 

u NG 

NND10 

NG 

1984. 0. 

n 

ASTIO 

2 OUT 

ASTID 

NG 

1984. 0. 

0 

ASTIO 

1 NG 

ASTIO 

NG 

^98L. n. 

U _ 


„ ^ 

_ „ 

^ _ 


TTC5 


OK 


1984. 0. 4 
3000. 0. 0 


.SHUT 

TUG 


lO" REFURBISHEO 


TERMINATF SIMULATION 




0 

1 

H-i 

U) 


" 

TIME 

SYSTEM 

— n — ux- 

STATUS 

SATELLITE 

STATUS 

module 

STATUS 


1933. 1. 2 

ASTIO 

1 OUT 

ASTIO 

available 




1983. 2.27 

ASTID 

1 OUT 

ASTIO 

LAUNCHED 




iq«^. P.P7 

A9T1 n 

1 fH^ 

AST1H 

ni^ 




1983. 8.19 

ASTID 

1 OUT 

ASTIO 

OUT 

TTC5 

OUT 


1983,11. 19 

ASTID 

1 OUT 

ASTID 

OUT 

TTC5 

LAUNCHEO 


1983. 11. J9 

ASTIO 

1 OK 

ASTID 

OK 

TTC5 

OK 

4 

i9aa. n. n . 

AST in 

1 nr: 

ASTI (1 




a 

CHROMOLOCICAL TIME 

HISTORY OF 

SATELLITE 

POSITION IN 0K8IT 



TIME 

SYSTEM 

STATUS 

SATELLITE 

STATUS 

MODULE 

STATUS 


1. ? 

AST1 n 

7 BUT 

AST1 n 

AUATI ARI F 




1983. 2.27 

ASTIO 

2 OUT 

ASTIO 

LAUNCHED 




1963. 2.27 

ASTID 

2 OUT 

ASTIO 

OK 




1964. Q. 0 

ASTIO 

2 OUT 

ASTIO 

NG 




CHRCNOLOCICAL TIME 

HISTCRV OF 

SATELLITE 

POSITION IN ORBIT 



TIME 

SYSTEM 

STATUS 

SATELLITE 

STATUS 

MODULE 

STATUS 


1980. 3.28 

NN01A9 

1 OUT 

NNDIA 

AVAILABLE 




iq«n. 9. 7P. 

NNO 1 A 8 

1 OUT 

NNOI A 

1 A 1 IMf! M P n 




1980. 9.26 

NNO1A0 

1 OUT 

NNOIA 

OK 




1980. 7. 16 

NNDIAR 

1 OUT 

NNOIA 

OUT 

TTCl 

OUT 


1980. 8.26 

NNOIAB 

1 OUT 

NNOIA 

OUT 

TTCl 

LAUNCHED 


1980. 8.?6 

NNDIAH 

1 OUT 

NNDi A 

OK 

rmi 

OK 


1961.11. 20 

NNDIAB 

1 OUT 

NNOIA 

OUT 

NNO 12 

OUT 


1982. 2.28 

NNDl AB 

1 OUT 

NNOIA 

OUT 

NN012 

LAUNCHEO 


1982. 2.20 

NNOIAB 

1 OK 

NNOIA 

OK 

NN012 

OK 


1 ^ . f1 • 11 

NNOIAB 

1 OUT . . 

NNOI A 

NPI 




CHRONOLOGICAL TIME 

HISTORY OF 

SATf LLITE 

POSITION IN ORBIT 



TIME 

SYSTEM 

STATUS 

satellite 

STA TUS 

MODULE 

STATUS 


1980. 3.28 

NNOIAR 

7 OUT 

NNOI B 

A 1/ A T( API P 




1980. 3.26 

NNDIAP 

2 OUT 

NN018 

LAUNCHED 




1980. 3.28 

NNOIAB 

2 OUT 

NNOIB 

OK 




1°81. 3. 1 

NNOIAB 

2 OUT 

NNOIB 

our 

AVCS7 

OUT 


1981. 3.2? 

NNOI AB 

? ni 1 T 

WNOI H 

ntlT 

At/nS7 

LAUNr.HFD 


1981. 3.22 

NNOIAB 

2 OUT 

NNDIS 

OK 

AWCS7 

OK 


1981. 5, Q 

NNOIAB 

? OUT 

NNOIB 

OUT 

AVCS7 

OUT 


1981, 6. 0 

NNO 1 A e 

2 OUT 

NNOIB 

OUT 

AVCS7 

LAUNCHED 


1 Q Ai m A n 

NNOI AR 

2 OUT 

MNni R 

OK 

AVCS7 

OK 


1982. 6.13 

NNDIAB 

2 OUT 

NNOIB 

OUT 

EPS2 

OUT 


1982. 6.13 

NNOIAB 

2 OUT 

NNOIB 

OUT 

EPS2 

OUT 


1982. 6.17 

NNOIAB 

2 OUT 

NNOIB 

OUT 

EPS2 

LAUNCHEO 


1 982. fi.17 

NKin '1 A P 

2 OUT . _ 

NNOI H . 

nuT 

FPS? 

1 AUNCHFO 


1982. 6.17 

NN01A8 

2 our 

NNOIB 

OUT 

EPS 2 

OK 


1982. 6.17 

NNOIAB 

2 OUT 

NNOIB 

OK 

EPS2 

OK 


1983. 2.27 

NNOIAB 

2 OUT 

NNOIB 

OUT 

AVCS2 

OUT 


198.7. 9. fi 

Nwni AB 

-2. OUT 

MNni B 

OUT 

Al/r.S7 

LAUNOHFn 


1983. 5. 6 

NNOIAB 

2 OUT 

NNOIB 

OK 

AVCS2 

OK 


1983. 6. 9 

NNOIAB 

2 OUT 

NN018 

OUT 

EPS2 

OUT 


1983. 6. 6 

NNOIAB 

? OUT 

NNOIB 

OUT 

EPS 2 

LAUNCHEO 


198.7. a. 6 _ 

NNOI AB 

7 OUT 

NNOI B 

OK 

FPS? 

OK 


198S. 0. 0 

NNOIAB 

2 OUT 

NNOIB 

NG 





fl- 


CHRONOLOGICAL TIME 

H 

ISTORY 

OF 

satellite 

POSITION IN ORBIT 


TIME 

SYSTEM 


STATUS 


SATELLITE 

STATUS 

MODULE 

STATUS 


NNH 1 AP 

_5- 

niiT 


LNni A 

AUAjj AQlIT 



1960. 3.28 

NNOIAS 

3 

OUT 


NNDIA 

LAUNCHED 



1980. 3.28 

NNOIAB 

3 

OUT 


NNQIA 

OK 



1980. 7.22 

NND1A3 

3 

OUT 


NNDIA 

OUT 

TTCl 

OUT 

•1 PHn , n, 

WKirti flP 

3 

ntiT 


NNni a 

f)HT 

rm 

1 Aiih>|rHFrf 

1980. 6.26 

NNDIAB 

3 

OK 


NNDIA 

OK 

TTCl 

OK 

i981. 2. 7 

NNDIAB 

3 

OUT 


N'NOIA 

OUT 

AVCS5 

OUT 

1981. 3.22 

NNOIAB 

3 

OUT 


NNDIA 

OUT 

AVCS5 

LAUNCHED 

1 Pfti . 3. ?? 

NNOI AR 

3 ntf 


NNQ 1 a 

ni< 

Awr.SF 

nx 

1982. 3.17 

NNOIAS 

3 

OUT 


NNOIA 

OUT 

AVCS? 

OUT 

1982. 6. 17 

NNDIAB 

3 

OUT 


NNOIA 

OUT 

AVCS? 

LAUNCHED 

1982. 6.17 

NNOIAB 

3 

OK 


NNOIA 

OK 

AVCS? 

OK 

iPAI. P. A 

Kiwm An 

7 

miT ^ 



nj iT 

aun<:7 

niiT 

1983. 6. 6 

NNOIAB 

"t 

OUT 


NNOIA 

OUT 

AVCS? 

LAUNCHED 

1983. 8. 6 

NNOIAB 

3 

OK 


NNDIA 

OK 

AVCS7 

OK 

1983.10. 7 

NNOIAB 

3 

OUT 


NNOIA 

OUT 

A VC SB 

OUT 

i SAIl . ft* JL 

_NMn_1_AR _ 

R 

niDT 


luNni A 

wr; 



CHROhOLOGlCAL TIME 

HISTORY 

OF 

SATELLITE 

POSITION IN OR6IT 


TIME 

SYSTEM 


STATUS 


SATELLITE 

STATUS 

MODULE 

STATUS 

IPAIl. P. 

NNni AR 

u 

miT 


K «n 1 R 

Ai/ATi am r 



1980. 8.26 

NNOIAB 

4 

OUT 


NNOIB 

LAUNCHED 



1980. 8.26 

NNOIAB 

4 

OUT 


NNDia 

OK 



1981. 0.22 

NNOIAB 

4 

OUT 


NNO10 

OUT 

NN012 

OUT 

1 PB1 . 3. 77 

NN01 AR 

_U_ 

OUT 


NNni R 

ntiT 


1 AtiMriHPn 

1981, 3.22 

NNOIAB 

4 

OUT 


NNOIB 

OK 

NN012 

OK 

1981, 5. 1 

NNOIAB 

4 

OUT 


NNDIB 

OUT 

AVCS? 

OUT 

1981. 5, 9 

NNDIAB 

4 

OUT 


NNOIB 

OUT 

DPI 

OUT 

.. .. 1 PB1 - 7. P 

wwn 1 Aft 

If 

niiT 


kiKini R 

niiT 

AurcR 

niiT 

1981. a. 0 

NNOIAB 

4 

OUT 


NNOIB 

OUT 

AVCS7 

LAUNCHED 

1981. 8. 0 

NNOIAS 

4 

OUT 


NNOIB 

OUT 

DPI 

LAUNCHED 

1981. 8. 0 

NNDIAB 

4 

OUT 


NNOIB 

OUT 

AVCS5 

LAUNCHED 

i PAi . ft. n 

kjKin i A n 

_4, 

niiT 


wwn-t ft 

niiT 

A1/f;R7 


1981. 8. Q 

NNDIAB 

4 

OUT 


NNOie 

OUT 

Dpi 

OK 

1981. 8. 0 

NNDIAB 

4 

OK 


NNOIB 

OK 

AVCSS 

OK 

1982. 2.16 

NNOIAB 

4 

OUT 


NND18 

OUT 

EPS2 

OUT 

ip«7. ?* ?n 

NNni AR 

_k. 

niiT 


NNni R 

nuT 


1 AHMrHFn 

1982. 2.20 

NNOIAB 

4 

OUT 


NNOIB 

OK 

EPS 2 

OK 

1982. 9. 6 

NNOIAB 

4 

OUT 


NN018 

OUT 

AVCS2 

OUT 

1983. 0. 6 

NNDIAB 

4 

OUT 


NNOIB 

OUT 

AWCS2 

LAUNCHED 

1PA3*_0. A.. 

KlK|n A Q 



Nkini R . . 


A i/p C9 

r\)c 

1983. 3.22 

NNOIAB 

4 

OUT 


NNOIB 

OUT 

£PS2 

OUT 

1983. 5. 6 

NNOIAB 

4 

OUT 


NNOIB 

OUT 

EPS2 

LAUNCHED 

1983. 5. 6 

NNOIAB 

4 

OUT 


NND18 

OK 

EPS2 

OK 

1PA3, P.p7 

hJMp 4 Q 


niiT , 


^KnjH _ 

mil 

^ yp ^7 

niir 

1934. 0. 0 

NNOIAB 

4 

NG 


NNOIB 

NG 



CHRONOLOGICAL TIME 

HISTORY 

OF 

SATELLITE 

POSITION IN ORBIT 


TTHP 

'^YBTFM 


- SATELLITE 

cy rtj Ti to 

Mnnijj P 

STATUS 

1982, 1. 2 

SORT7 

1 

OUT 


SORT? 

AVAILABLE 



1982. 1. 2 

SORT? 

1 

OUT 


SORT? 

LAUNCHED 



1982. 1. 2 

SORT? 

1 

OK 


SORT? 

OK 



1382* 1*.J9 

SQRIZ- 

_L 'IGi- . 


-SOfilZ 

-REMOVED-- 




STATISTICAL SUMMARY FOR 25 MOMTE CARLO CYCLES 


TEAR 

JLaaJd- 


1981 

1982 

1983 


PERCENT 
OFl AT 


FLIGHT SUMMA’rY 
SHUTTLE TUG 


MIN 

U 

AVG 
A . 2 

MAX 

MIN 

u 

AVG 

4 , g 

1 

2.2 

3 

1 

2.2 

2 

3.2 

5 

1 

2.2 

1 

3.0 

5 

i 

3.0 

_ - 11 

_12^7__ 

-_1^ 

to 

11.7 

0.0 

0.0 

O.Q 

0 . a 

0.0 

— O^Q 

r .0 

JLJL 

0-.J1 



SEPS 


MAX 

q 

MIN 

f) 

AYG 

0 irO 

MAX 

0 

3 

0 

0.0 

d 

t 

Q 

0.0 

0 

5 

0 

0.0 

a 

- JL5 

G- - 

' — 

---0- 

a.G 

0.0 

0.0 

0.0 

... 0.0 . 

JUJ] 

0.0 

JLJL 



9T- 


ORBIT TRAFFIC SUMMART 



AVFRAf^F 

FI JflHT 


AUF RACF HP WFinUT 

<;huTT< f 

ORBIT 

SHUTTLE 

TUC 

SEPS 

SHUTTLE 

TUG 

SEPS 

LOAD FACTOR 

SNC/0 

Q. 0 

11.7 

0. Q 

0. 

3179 , 

0. 

0.00 


n, r. 

(1 f 0 _ 


0 t 


0 . 

0 1 00 

SORT 

1. 0 

0.0 

O.G 

lOOOQ. 



Q . 

0. 

0.16 


O 



-17 


O 


M03ULF MIN 

AVG 

MAX 

MIN FLT 

AVG FLT 

MAX FLT 

NAsriClOO 




n 

- 0 - 

n* ? 

7 

fi - nn 

0„0fe 

_4j—axL 

AVCS5 0 

Avcsr « 







AVCS7 0 

Avn<?7 n 







AVCS7 D 

GNl 0 

Q 

0.2 

1 

Q.OO 

0.07 

0.54 

GN2 0 

0 

0,0 

1 

0.00 

0.02 

C. 38 

TTfii; r 

n 

n. n 

1 

fl . n n 

n . 

•1 . nn 

OPl 0 

EPSIA 0 

0 

B.l 

1 

0.00 

0.03 

0.39 

ASTICI 0 
SATPII TTF 

0 

0.1 

1 

D.OO 

0.05 

0.65 

ASTID 


1.0 


0.40 

0 .49 

0.76 

EQ SAT 


1. OF 



SAIFI LTTF rnrfit 

Ft TRHTS 


n-77 

1 . 7fl 

PERCENT SATELLITE AVAIL. 

26.55 

85.05 

130.00 

nFLAT TNTFRVAI 

JLO RESXQfiF 

?-qq 


qn . fin 

MODULE MIN 

AVG 

MAX 

MIN FLT 

AVG FLT 

MAX FLT 

NASTlCltlD 
Avns.i n 

JJ 

n.n 



n.n? 

n - Afi 

AVCS5 0 

0 

0.1 

1 

0.00 

0.02 

0.30 

AVCS7 0 
AVCS7 0 
AVRS7 0 

0 

0.0 

1 

0.00 

3.01 

0.25 

AVCS7 n 

6Ml 0 

0 

0.2 

1 

O.QG 

0.05 

0.39 

GN2 0 

0 

0,2 

1 

0.00 

3 .05 

0.40 

JXC5 0 

J1 

0-1 

1 

0.00 

0.(11 

r, . ?6 

OPl tJ 

0 

0.1 

1 

0.00 

0.03 

0.49 

EPSIA t1 

1} 

0.0 

1 

0.00 

0.02 

0.39 

ASTICI *'0 

0 

0.0 

1 

0.00 

0.04 

1.00 


ASTIO 1.0 

EQ SAT 1.06 

0.30 

0.47 

0.50 

SATELLITE TOTAL FLIGHTS 

n.3 0 

0.7? _ 
84.37 

1 -7(1 

PERCENT SATELLITE AVAIL. 

35.89 

100.00 

DELAY INTERVAL TO RESTORE 


5ft. 6n 

. -Kit 

SYSTEM TOTAL FLIGHTS 

0.88 

1.49 

2.20 

PERRFNT SYSTFM AVATlAflIF 

74.68 

71.73 

1 n n . ii n 

DELAY INTERVAL TO RESTOR‘D 

2.99 

6 2 .48 

95.97 



STATISTICS FCR SYSTEM - NNOIAB 


Mrmii p 

MTN 

a \ir. 

.MAy_ . 

JilN -ELT- 

AJ.G FLI- 

MAX F-LJ 

NNNDl : 

LOO 







AVCSZ 

C 

0 

n.l 

1 

0.00 

0.03 

0.49 

AVCS5 

0 

0 

0.6 

2 

0.00 

0.32 

2.00 

AUPg? 

— 0- 


-1 

o--oa 

0^-13 

i*ao - 

AVCS7 

0 

0 

0.3 

2 

0.00 

O.IG 

0.99 

AVCS7 

n 

0 

Q.2 

1 

0.00 

G .04 

0.49 

AVCS7 

P 

0 

0.1 

1 

0.0 0 

0.03 

0.50 

m2. — 

0- 


_ Z 


0-.17 

-2.04J 

TTCl 

0 

Q 

0.2 

1 

0.00 

0,09 

0.51 

QPt 

g 

0 

a . 2 

1 

G.DO 

D.OS 

0.51 

EPS? 

0 

0 

0.2 

2 

0.00 

0.12 

1. 21 


n 

_a_. 

n . 1 

L. 

()*nn 

-4)-JL5 _ 

— q .61- 

EPS2 

P 

(3 

0.2 

1 

o.bo 

0.11 

1.00 

EPS2 

0 

0 

0.1 

1 

0. 00 

0.02 

0.32 

EPS2 

0 

0 

0.3 

1 

C.QO 

0.14 

i.OQ 

EES2 

B_ 

n 

— lua 

1. 

_ a.jia 

ruJi2 

A.-33 

HP SI 

n 







EPS3 

n 







NNQll 

0 

0 

0.2 

2 

0.00 

0.12 

1.00 



n 

n, 7 .. 


a^EO-- 

E. 1 P 

- lUJZ - 

SATELLITE 







NNOIA 



1.2 


0.89 

1.18 

3.00 

£Q SAT 



t.3q 





SATELLITE TOTAL FLIGHTS 

'iToo 

2.83’ 

“5.64 

PERCENT 

SATELLITE AVAIL. 

44.95 

78.05 

94.02 

DELAY INTERVAL 

TO RESTORE 

■”6124 

~~7T777 

95.86 

MOODLE 

MIN 

AVG 

MAX 

MIN FLT 

AVG FLT 

MAX FLT 

NNMni 

inn 







AVCSZ 

0 

0 

0.3 

T 

oTbo 

dT07 

"q.38 

AVCS5 

0 

0 

0.3 

2 

0.00 

Q.ll 

1.51 

AVCS7 

0 

0 

0.3 

2 

0.00 

0.09 

1.00 

AU!T:<;7 

a. 

n 

n. 1 


, rt. nn 

^I1Z_ 

i . nn 

AVCS7 

c 

0 

0.2 

1 

0.00 

0 .04 

0.27 

AVCS7 

0 

0 

0.4 

2 

0.00 

Q.IC 

1.00 

GN2 

0 

0 

0.3 

2 

o.oc 

Q.15 

1.48 

TTCj IL- 

-JL 


_ „ 1 

ji^oa 


-H*23 

DPI 

0 

0 

0.2 

2 

0.00 

0.05 

0.87 

EPS2 

0 

0 

0.2 

1 

0.00 

0.09 

1.00 

EPS2 

0 

0 

0.3 

1 

O.QO 

0.12 

Q.61 

HPS2 . 

— 0_ 



... 


_ 

- _ 

EPS2 

r 

0 

0.3 

2 

0.00 

0.14 

1.00 

EPS2 

0 

0 

0.2 

1 

0.00 

0.06 

0.61 

EPS2 

n 

0 

0.2 

1 

0.00 

0.05 

0.50 

. JEE53. 

n 


n.n ■ 

_ - I 

0-.M 

. luna- 

0.-08 

EPS3 

Q 







NNQli 

0 

Q 

0.2 

1 

0.00 

0.06 

0.65 



-19 


NN012 C 0 

^ATELLITF 

0.1 1 

0.00 

0.04 

C.70 


jtuiiia 

EQ SAT 

.i. 

1 .SG 

1.00 

1.07 

1.92 


SATELLITE TOTSL 

FLIGHTS 

l.Cd 

2.37 

4.23 


PERCENT SATELLITE AVAIL. 

63.34 

84.77 

96.97 


DELAY INTERVAL 

TO RESTORE 

0.22 

61.03 

96.53 

§ B 

hooule' min 

NNNOl iOn 

AVG MAX 

MIN FLT 

AVG FLT 

MAX FLT 


AVCS2 0 0 

0.1 1 

O.OJ 

0 .05 

1.00 

Es 

AVCSS D _JL - 

. JX..a_ 2 


fi.23 

A. 03 

AVCS7 C 0 

0.2 ? 

0. 00 

0.09 

1.00 

AVCS7 0 0 

0.2 i 

O.OQ 

0.07 

0.50 

AVCS7 0 0 

0 3 1 

0.00 

0.08 

0.50 

— AVCa? Q J3 . 

JL..JI i 

MAO. 

0.09 

o.so 

GN2 0 0 

0.3 2 

0.00 

0 .15 

1.31 

TTCl 0 0 

0.2 1 

0.00 

0.04 

0.34 

OPl 0 0 

0.1 1 

0.00 

0.C3 

0.51 


£P^2 Q fl 

2 

G.QQ 

0.0 9 

Q.SQ 


EPS2 0 0 

0.1 1 

0.00 

0.06 

1.00 

EPS2 0 0 

0.1 1 

O.OQ 

0 .08 

1.00 

EPS2 0 0 

0.2 1 

0.00 

0.08 

0.61 


FPS2 n n 

JL.-2 2 

A. 00 

D.JJ 

1.24 


EP S2 0 0 

EPS3 '' 

EPS3 0 

0.2 1 

u. 00 

0.10 

G . 61 


_ JltiQli. . J1 JL _ 

fl.l 1 

O.OQ 

Q.Q6 

1. 00 


NND12 0 0 

SATELLITE 

0.2 1 

0.00 

0.09 

0.71 


NNOIA^ 

1.1 

i.Jll._ 

1.00 

1.10 

1. 92 


SATELLITE TOTAL 

FLIGHTS 

1.00 

2.65 

4.59 


- JERCEH.T -S A.IEJ.LU£ MAIL. 

64. 3o 

32.77 

100. QO 


DELAY INTERVAL 

TO RESTORE 

7.78 

70.49 

95.86 


-MflaULE JIZN MG MAX 

NNNOl ICO 

BIM.FLT 

AVG ELI 

MAX ELI 


AVCS2 0 0 

0.2 1 

0.00 

0.12 

1.00 


AVCS5 0 0 

0.3 2 

0.00 

0.10 

1. QG 


Mca?. .. . J1 Jl 

Q.A. ^ 

D.OA 

Q.12 

O.SM 


AVCS7 0 0 

0.2 1 

0.00 

0.09 

1.00 


AVCS7 0 0 

0.2 1 

0.00 

Q .06 

Q.51 


AVCS7 0 0 

0.1 1 

0.00 

0.01 

C.14 


RN? on 

2 

o..aa 

0.3.0 

0.76 


TTCL 0 0 

0.1 1 

O.QO 

0.06 

1.00 


OPl 0 0 

0.2 1 

c.co 

C .06 

0.49 


EPS2 0 0 

0 1 i 

0. 00 

0.02 

0.37 


. EPS2 0 n 

0.2 _i. 

- „ fl-iAA 

A..10 

1.00 


EPS2 n a 

0.2 1 

0.00 

0.12 

1.00 


EPS2 0 0 

0.2 1 

0.00 

0.07 

1.00 




EPS2 0 0 fl.2 1 

£PS2 00 0.2 1 

FP<5s n 

0.00 

Q.OO 

0.07 

0.06 

0*61 

0.62 

EPS3 Q 

NNQll 0 0 0.0 1 

NN012 0 0 0.1 1 

I jjf 

0. 00 
0.00 

0.02 

0.07 

0.54 

0.71 

NNDIB 1.2 

EQ SAT 1.33 

0.6d 

1.09 

2.00 

1 ttf rnrai F| t<^hts 


2 * 3 (* 


PERCENT SATELLITE AVAIL. 

67.75 

84.46 

100.00 

rjFi AY TNTFPVAt rn UF'^jnRF 

:?.q3 

B7 .Sfi 

Qfi • nU 

SYSTEH TOTAL FLIGHTS 

6.46 

10.19 

13.10 

PFSnFWT SY^TFM fltfATIflRIF 

1 



flELAY interval TO RESTCRE 

12.41 

100.66 

229.06 


STATISTICS FOR SYSTEM - 
<;aTFiiTTF 

SORT7 



SORT?' 1.0 

1.00 

l.OC 

l.QQ 

SYSTEM TOTAL FLIGHTS 

1.00 

l.CC 

1 • 0 u 

PERCENT SYSTEM AVAILABLE 

100.00 

100. oc 

lOL. 00 

DELAY INTERVAL TO RESTORE 

0.00 

0.00 

O.QQ 


. 6 ^.. 

7.39 


T O TAL S A Tfl llTFS 
EQU. SATELLITES 




MOOULF SUMM/'i?Y 




WA kM 



FAIL 



RtPLACE 

NAME 

MIM 

AV9 

MAX 

ilIN 

AV-^ 

1AX 

MIN 

AVR 

A'/C S2 

rt 

j 

U. 0 

0 

r 

0 . 0 

3 

0 

0.7 

TTP5 

o 

3. J 

r* 

J 

c 

0.2 

2 

Q 

C. 1 

IPj 

c 

n. a 

0 

0 

0.7 

3 

C 

C.7 

lA 

0 

Q< Li 

0 

c 

0.2 

1 

0 

0.1 

EPS 2 

0 

0.0 

0 

0 

4.2 

7 

0 

4. 0 

‘^’FS 3 

n 

C • u 

J 

0 

0. 0 

1 

J 

0*0 

ASTl^'l 

n 

0 

c, n 

c 

r 

O.i 

1 

0 

0.1 

A\/CS3 

0.0 

0 

0 

0.2 

2 

a 

0 . 2 

AVCSE 


r. c 

Li 

n 

o 

i.9 

4 

0 

1. • 7 

AYCS7 

J 

L. Q 

0 

2 

3. i 

8 

JL 

3 • 5 

fiNl 

n 

0. fi 

p 

0 

0.4 

■> 

U 

0.3 

GN? 

0 

C, J 

n 

c 

1.9 

5 

0 

1 . 5 

TTCl 


• L 

n 

n 

C . 6 

2 

0 

0 . 0 

NNOli 

0 

0. 0 

u 

n 

Li . 6 

3 

0 

G * 6 

NND12 

NA-^TiC 

T 

C. 0 

r 

v> 

C 

0.6 

2 

L 

0 * b 

NNNT1 
MCn ULF 

T 

J 

.*> 

1' • 1 

1 

n 

0.6 

2 

0 

G . J 


o o 

§1 


MAX 




th fo — < fs. -H CM j- tj in oj ro tv) 




